VEXguacamole
guacamole
1 بيان, صدرت في .كل بيان نتيجةٌ من الماسح غير قابلة للاستغلال في هذه الصورة، مع السبب.
@id https://quench-works.com/vex/guacamole/2026-10-22
CVE-2026-113730
غير متأثر · لا يستطيع المهاجم التحكم بالشيفرة المعرّضة- ognl 3.4.4
CVE-2026-113730 (GHSA-crwc-vw2r-qr6m) lets an OGNL EXPRESSION reach blocked methods through java.lang.reflect proxies, bypassing the stricter-invocation block list. It needs the attacker to author the expression text. Here ognl 3.4.4 exists only relocated to org/apache/ibatis/ognl inside mybatis-3.5.19.jar, nested in /etc/guacamole/extensions/guacamole-auth-jdbc-postgresql-1.6.0.jar (checked with unzip -l on the published 1.6.0 image: META-INF/maven/ognl/ognl/pom.properties version=3.4.4; no other ognl copy in any of the image's 83 jars). MyBatis evaluates OGNL only for expressions written in mapper XML: the 21 *Mapper.xml files shipped in that jar hold the only expressions, all constant, e.g. UserPermissionMapper.xml:76 test="caseSensitivity.caseSensitiveUsernames()"; the ${caseSensitivity}/${entityID}/${groups}/${column} placeholders are <include> properties fixed at parse time (SystemPermissionMapper.xml:42-43). Request data reaches MyBatis only as #{...} bound parameter values, never as expression text, and no Guacamole class references org.apache.ibatis.ognl directly (grep of guacamole-auth-jdbc-base-1.6.0.jar). The fix is unreleased for this path: mybatis 3.5.19 is the newest release on Maven Central and still shades ognl 3.4.4 (master moved to 3.4.16, not yet released). Drop this statement when a mybatis release ships ognl 3.4.13 or later inside a Guacamole JDBC extension.