CWE-1023

An Incomplete Comparison with Missing Factors vulnerability in the Gallagher Controller allows an attacker to bypass PIV verification. This issue affects: Gallagher Command Centre 8.40 versions prior to 8.40.1888 (MR3); 8.30 versions prior to 8.30.1359 (MR3); 8.20 versions prior to 8.20.1259 (MR5); 8.10 versions prior to 8.10.1284 (MR7); version 8.00 and prior versions.

Incomplete comparison with missing factors in Windows BitLocker allows an unauthorized attacker to bypass a security feature with a physical attack.

On affected platforms running Arista EOS where a tunnel decapsulation configuration—such as VXLAN (Virtual Extensible LAN), decap-groups, or a GRE (Generic Routing Encapsulation) tunnel interface—is present, the switch will incorrectly decapsulate and forward other unexpected tunneled packet with a destination IP matching its configured decapsulation IP. This occurs because the switch does not verify the tunnel protocol type, potentially leading to the unexpected processing of non-configured tunnel traffic. This issue has been reported as being exploited in the wild.

An issue was discovered in GitLab CE/EE affecting all versions prior to 16.11.6, starting from 17.0 prior to 17.0.4, and starting from 17.1 prior to 17.1.2, which allows a subdomain takeover in GitLab Pages.

Versions of the package jsrsasign from 7.0.0 and before 11.1.1 are vulnerable to Incomplete Comparison with Missing Factors via the getRandomBigIntegerZeroToMax and getRandomBigIntegerMinToMax functions in src/crypto-1.1.js; an attacker can recover the private key by exploiting the incorrect compareTo checks that accept out-of-range candidates and thus bias DSA nonces during signature generation.

An issue was discovered in Django 5.2 before 5.2.15 and 6.0 before 6.0.6. `django.utils.cache.has_vary_header()` in Django does not strip leading or trailing whitespace from `Vary` response header values before comparison, which allows remote attackers to read cached responses via requests to URLs whose responses contain whitespace-padded Vary header values. Earlier, unsupported Django series (such as 5.0.x, 4.1.x, and 3.2.x) were not evaluated and may also be affected. Django would like to thank Navid Rezazadeh for reporting this issue.

OpenClaw before 2026.5.7 contains a hostname validation vulnerability in retry endpoint checks that allows matching hostname prefixes instead of exact hostnames. Attackers can exploit this by crafting a hostname prefix resembling a trusted host to send authentication material to untrusted endpoints.

vLLM is an inference and serving engine for large language models (LLMs). In versions starting from 0.7.0 to before 0.9.0, in the file vllm/multimodal/hasher.py, the MultiModalHasher class has a security and data integrity issue in its image hashing method. Currently, it serializes PIL.Image.Image objects using only obj.tobytes(), which returns only the raw pixel data, without including metadata such as the image’s shape (width, height, mode). As a result, two images of different sizes (e.g., 30x100 and 100x30) with the same pixel byte sequence could generate the same hash value. This may lead to hash collisions, incorrect cache hits, and even data leakage or security risks. This issue has been patched in version 0.9.0.

A regression in the way hashes were calculated caused rules containing the address range syntax (x.x.x.x - y.y.y.y) that only differ in the address range(s) involved to be silently dropped as duplicates. Only the first of such rules is actually loaded into pf. Ranges expressed using the address[/mask-bits] syntax were not affected. Some keywords representing actions taken on a packet-matching rule, such as 'log', 'return tll', or 'dnpipe', may suffer from the same issue. It is unlikely that users have such configurations, as these rules would always be redundant. Affected rules are silently ignored, which can lead to unexpected behaviour including over- and underblocking.

OpenClaw before 2026.5.26 contains a hostname validation vulnerability allowing attackers to bypass blocklist comparisons using trailing-dot notation in model or workspace-derived URLs. Attackers can exploit inconsistent hostname checks to reach destinations that operators intended to block through hostname policies.

BullWall Ransomware Containment may not always detect an encrypted file. This issue affects a specific file inspection method that evaluates file content based on header bytes. An authenticated attacker could encrypt files, preserving the first four bytes and preventing this particular method from triggering. The affected product implements additional integrity-based detection mechanisms capable of identifying file corruption or encryption for some common file extensions independent of header bytes. As a result, this vulnerability does not represent a complete bypass of ransomware detection, but a limitation of one detection method when evaluated independently. Versions 4.6.0.0, 4.6.0.6, 4.6.0.7, and 4.6.1.4 are affected. Other versions may also be affected. BullWall plans to improve detection method documentation.

### Description `Symfony\Component\HtmlSanitizer\Visitor\AttributeSanitizer\UrlAttributeSanitizer::getSupportedAttributes()` enumerates the attribute names whose values are scrubbed through `UrlSanitizer::sanitize()` (scheme and host allow-lists, `javascript:` rejection, BiDi check, etc.). The list is `['src', 'href', 'lowsrc', 'background', 'ping', 'action', 'formaction', 'poster', 'cite']`. Other URL-bearing attributes are absent: `<object data=…>`, `<applet codebase=…>`, `<applet archive=…>` and `<object archive=…>`, `<iframe longdesc=…>` and `<img longdesc=…>`. When an integrator opts these elements/attributes in via `allowElement('object', ['data'])`, `allowElement('applet', ['codebase'])`, etc., or via `allowAttribute()`, no URL sanitization runs: `data="javascript:alert(1)"` and similar payloads ship through unchanged into the output, enabling stored XSS. `<meta http-equiv="refresh" content="0; url=…">` is the same class of bug routed differently: the URL is embedded inside a multi-field `content` attribute that the per-attribute sanitizer cannot detect from the attribute name alone. Integrators who enable `<meta>` with the `content` attribute (e.g. via `allowStaticElements()`) see `content="0; url=javascript:alert(1)"` pass through, producing a refresh-driven navigation to a `javascript:` URL. Default configurations are not affected: `<object>`, `<applet>` and `<iframe>` are not in `W3CReference::BODY_ELEMENTS` and `<meta>` requires an explicit opt-in to `<head>` context. The vulnerability surface is integrators who explicitly allow any of those elements together with the listed URL-bearing attributes. ### Resolution `UrlAttributeSanitizer` now also routes `data`, `codebase`, `archive` and `longdesc` through `UrlSanitizer::sanitize()`. A new `MetaRefreshAttributeSanitizer` registered as a default attribute sanitizer detects the `<delay>; url=<url>` syntax inside `<meta content>`, sanitizes the embedded URL, and drops the attribute if the URL is rejected; non-refresh meta `content` values are passed through unchanged. The patches for this issue are available [here](https://github.com/symfony/symfony/commit/069a70f9f26e61e9de3b7f9a864a86ed24b36bd0) for branch 6.4 (and forward-ported to 7.4, 8.0 and 8.1). ### Credits Symfony would like to thank Scott Arciszewski (Trail of Bits) for reporting the issue and Nicolas Grekas for providing the fix.