Recently added

SD JWT JS: Tampered disclosures silently dropped instead of rejected

When one Disclosure in an SD-JWT presentation is tampered so its digest no longer matches the Issuer-signed _sd array, @sd-jwt/decode 0.19.0 does not reject the presentation. It silently drops the unmatched Disclosure and returns a reduced claim set, reporting success. The Issuer signature is untouched and valid. This is a downgrade/omission primitive. A malicious or curious holder can present a tampered Disclosure and have the relying party receive fewer claims …

SD JWT JS: Tampered disclosures silently dropped instead of rejected

When one Disclosure in an SD-JWT presentation is tampered so its digest no longer matches the Issuer-signed _sd array, @sd-jwt/decode 0.19.0 does not reject the presentation. It silently drops the unmatched Disclosure and returns a reduced claim set, reporting success. The Issuer signature is untouched and valid. This is a downgrade/omission primitive. A malicious or curious holder can present a tampered Disclosure and have the relying party receive fewer claims …

DBHub: MySQL and MariaDB comment interpretation bypasses read-only SQL validation

The read-only mode can be bypassed on the MySQL and MariaDB connectors. In read-only mode a caller can still execute arbitrary write and DDL statements (for example DROP TABLE), which defeats the protection that read-only mode is meant to provide when a database is exposed to an AI agent. Root cause The problem is a mismatch between how DBHub's SQL parser handles single-line comments and how MySQL and MariaDB actually …

signalk-server has SSRF via absolute signalk.appIcon URL in the app store icon fetcher

The app store icon code (dist/appstore/icon-probe.js around line 200 and icon-bytes.js around line 138) resolves a plugin's declared signalk.appIcon. Relative paths are pinned to the CDN, but an absolute http(s) URL is used as-is: the server fetches it, follows redirects, and stores any image/* response as the plugin's icon, which is then served to the admin UI. Unrelated to GHSA-q59x-jc9f-gfqf.

russh's SSH client is susceptible to unbounded allocations via EXT_INFO packets

All evidence, reproduction steps, and scripts in the report were verified against a real running instance. Nothing is fabricated or synthetic; every verdict is backed by captured output from an actual deployment. Concretely, the evidence comes from executing the real russh v0.64.1 client packet parser (Session::process_packet handling handle_ext_info) in a live client session with attacker-supplied packet bodies in the pre-authentication state; the captured output below is from that real execution. …

russh's SSH agent server is susceptible to unbound allocations via repeated SSH_AGENT_CONSTRAIN_CONFIRM messages

All evidence, reproduction steps, and scripts in the report were verified against a real running instance. Nothing is fabricated or synthetic; every verdict is backed by captured output from an actual deployment. The SSH agent server that ships with russh (russh::keys::agent::server::serve) parses client key-addition requests and, for each SSH_AGENT_CONSTRAIN_CONFIRM (0x02) record it finds, pushes one Constraint::Confirm value into a per-key vector inside an unbounded loop, then stores the resulting pair …

Recently updated

Two LiteLLM versions published containing credential harvesting malware

After an API Token exposure from an exploited trivy dependency, two new releases of litellm were uploaded to PyPI containing automatically activated malware, harvesting sensitive credentials and files, and exfiltrating to a remote API. Anyone who has installed and run the project should assume any credentials available to litellm environment may have been exposed, and revoke/rotate thema ccordingly.