Loading story…
Two high-severity flaws in anchor-lang weakened account validation in Solana programs, allowing attackers to substitute unexpected accounts and potentially bypass authorization or alter program behavior. CVE-2026-45137 affects versions 1.0.0 through before 1.0.2 and stems from Program<'info, System> being validated through generic Program<T> logic that treated the system program like an untyped program because both resolved to Pubkey::default(). As a result, applications expecting the real Solana system program could accept any executable program account instead, creating risk of arbitrary cross-program invocation, payment bypass, or incorrect assumptions around account creation and other system-program operations.
A separate InterfaceAccount bug, tracked as GHSA-429q-fhh4-r6hj, affected anchor-lang 1.0.0-rc.1 after a change disabled checked deserialization and left validation relying mainly on owner checks. That flaw allowed accounts with unexpected Anchor discriminators to be passed as valid interface accounts, enabling account-type substitution and possible state or authorization bypasses. OtterSec fixed the InterfaceAccount issue in pull request #4139 and released it in 1.0.0-rc.2, restoring checked deserialization while preserving an explicit unchecked path; the Program<System> validation flaw was fixed in 1.0.2 by separating typed and untyped program validation and enforcing a match to the real system program ID.
See affected versions and whether adversaries are exploiting it.
10 events from the most recent confirmed update back to the earliest known activity.
RustSec issued advisory RUSTSEC-2026-0146 for the high-severity InterfaceAccount validation vulnerability in anchor-lang. The advisory states it was issued on 2026-05-19.
RustSec issued advisory RUSTSEC-2026-0144 for the high-severity Program<System> validation vulnerability in anchor-lang. The advisory states it was issued on 2026-05-18.
OtterSec released anchor-lang 1.0.0-rc.2 containing the fix for the InterfaceAccount substitution issue, restoring checked deserialization for InterfaceAccount::try_from. The content confirms the fixed version but does not explicitly anchor the release date.
The InterfaceAccount account-substitution vulnerability in anchor-lang was reported to the project. The RustSec advisory explicitly gives the report date as 2026-05-08.
Anchor fixed the Program<System> validation flaw in version 1.0.2 by separating typed Program<T> validation from the untyped path and enforcing the real system program ID check. This remediation is described in the advisory, but no explicit release date is provided in the content.
The vulnerability later tracked as CVE-2026-45137 in anchor-lang's Program<System> validation was reported. The RustSec advisory states the report date was 2026-05-07.
The fix for unexpected account substitution in InterfaceAccount was merged into master, with code changes enforcing owner checks and checked deserialization while preserving a separate unchecked path. The merge and associated commit occurred on 2026-01-05.
Anchor pull request #4139 was published to remediate unexpected account substitution in InterfaceAccount by restoring stricter validation and adding security tests. The pull request publication date is 2025-12-19.
The Anchor pull request #3837 was merged into otter-sec:master after review and testing, cementing the change later linked to the InterfaceAccount vulnerability. The source states this merge occurred on 2025-11-19.
A change in Anchor pull request #3837 disabled discriminator checking in InterfaceAccount, creating the condition that later allowed unexpected account substitution between accepted interface-owned types. The pull request was published on 2025-08-12.
Vulnerabilities, threat actors, malware, products, organizations, and breaches Mallory has linked to this story.
See whether adversaries are exploiting this yet, and where the affected versions run in your environment.
7 references tracked. Mallory keeps watching after this page renders.
cvefeed.io
Open sourcegithub.com
Open sourcerustsec.org
Open sourcerustsec.org
Open sourcegithub.com
Open sourcegithub.com
Open sourcegithub.com
Open sourceMap indicators from this story to your assets and identify affected systems in minutes.
Every observed campaign, victim, and pivot linked to actors named in this story.
Malware, exploits, and IOCs connected to the activity described here.
YARA, Sigma, and Snort rules deployed to your SIEM as soon as they’re published.
Get matching new stories delivered to your team as they break — not the next morning.
Ask questions about this story and take action on the answers.
Other stories Mallory is tracking that overlap on entities, sources, or topic labels.
LangChain disclosed and patched **CVE-2026-44843**, an unsafe deserialization flaw in older runtime code paths that processed application-controlled run inputs, run outputs, and related payloads with overly broad `load()` allowlists. In versions prior to **0.3.85** and **1.3.3**, some paths could call `load()` with `allowed_objects="all"`, allowing attacker-supplied serialized constructor dictionaries to revive trusted LangChain-serializable objects instead of only the narrowly required classes. The issue does **not** enable arbitrary Python object deserialization, but it can still instantiate trusted LangChain classes with untrusted arguments. LangChain said exploitation requires applications to accept untrusted structured input, preserve nested attacker-controlled data in run data, and use vulnerable deserialization paths such as `RunnableWithMessageHistory`, `astream_log()`, or `astream_events(version="v1")`. The company warned the flaw could lead to persistent chat-history poisoning, prompt manipulation, unexpected object instantiation, and in some cases credential disclosure or server-side requests during object initialization. The fixes tighten `load()` and `loads()` behavior, address a related `_is_lc_secret` validation bypass, and are accompanied by guidance to migrate away from deprecated APIs and restrict deserialization to trusted manifests with narrow `allowed_objects` settings.
Jun 29, 2026
Two high-severity flaws were disclosed in widely used JavaScript libraries, exposing applications to sandbox bypass and arbitrary code execution. **CVE-2026-34208** affects SandboxJS before `0.8.36` and allows attacker-supplied code to evade protections on direct assignment to global objects by abusing an exposed constructor path. The bypass uses `this.constructor.call(target, attackerObject)` to reach the internal `SandboxGlobal` function while `Function.prototype.call` remains permitted, enabling arbitrary properties to be written into host global objects and persist across sandbox instances in the same process. A separate issue, **CVE-2026-41242**, impacts `protobufjs` before `8.0.1` and `7.5.5`, where attackers can inject arbitrary code into Protocol Buffers definition `type` fields and trigger execution during object decoding with a malicious schema. The flaw is tracked as **CWE-94** and carries a CVSS v4 rating reflecting network-reachable exploitation with high impact to confidentiality, integrity, availability, and downstream systems. Maintainers released fixes in SandboxJS `0.8.36` and protobufjs `8.0.1` and `7.5.5`.
Jun 29, 2026
Axios patched several high-severity vulnerabilities affecting its Node.js HTTP adapter, including **CVE-2026-40175**, a critical flaw in versions below `1.13.2` that Singapore's CSA said could enable unauthenticated **SSRF**, potential remote code execution, and full cloud compromise. Separate disclosures also detailed **CVE-2026-42264**, which affects Axios `1.0.0` through `1.15.1` and allows attacker-controlled values inherited from a polluted `Object.prototype` to alter request behavior, enabling credential injection, request redirection, SSRF to Unix sockets, arbitrary code execution during redirects, and weaker HTTP parsing. Axios fixed that issue in `1.15.2` after merging hardening changes into the main branch. A later advisory described **CVE-2026-44494**, another prototype-pollution gadget in Axios's handling of `config.proxy` that affects versions from `1.0.0` up to but not including `1.16.0`, with the `0.x` branch also tracked as affected below `0.32.0`. If an application already contains a separate prototype-pollution source, the flaw can silently route outbound Axios traffic through an attacker-controlled proxy, exposing **Authorization headers, cookies, and request bodies** while allowing forged responses and full man-in-the-middle interception. Axios addressed the issue in `1.16.0`, and a backport commit for the `0.x` line added null-prototype object merging and other hardening measures to reduce prototype-pollution risk.
Jul 10, 2026