CVE-2026-77846, a newly disclosed AshSqlite vulnerability, can allow attackers to access hidden or sensitive fields stored inside JSON and map columns when applications pass untrusted input to AshSqlite's get_path/2 functionality.
The Erlang Ecosystem Foundation's CNA issued the vulnerability entry on August 30, 2026. The issue affects AshSqlite, the SQLite data layer used by the Ash Framework. Although it involves database queries, CVE-2026-77846 is not SQL injection.
Instead, the AshS
CVE-2026-77846, a newly disclosed AshSqlite vulnerability, can allow attackers to access hidden or sensitive fields stored inside JSON and map columns when applications pass untrusted input to AshSqlite's get_path/2 functionality.The Erlang Ecosystem Foundation's CNA issued the vulnerability entry on August 30, 2026. The issue affects AshSqlite, the SQLite data layer used by the Ash Framework. Although it involves database queries, CVE-2026-77846 is not SQL injection. Instead, the AshSqlite vulnerability results from unsafe construction of JSON paths and the way SQLite interprets special characters in those paths.
How the CVE-2026-77846 AshSqlite Vulnerability Works
In affected releases, AshSqlite generated JSON paths using $."-style path construction through the expression:
path = "$." <> Enum.join(right, ".")
The individual path segments were neither escaped nor quoted. Consequently, a key intended to represent the literal name private.secret could instead be interpreted as two JSON levels. Characters such as ., [, ], and $ could similarly alter JSONPath interpretation.The GitHub advisory describes the flaw as “JSONPath injection in AshSqlite.SqlImplementation get_path”, stating that an attacker controlling a get_path/2 segment can traverse nested JSON and disclose private fields. The affected package is ash_sqlite, with versions 0.1.2-rc.0 through before 0.2.18 affected and 0.2.18 listed as the patched release.The flaw remains separate from SQL injection because the generated JSON path is supplied to SQLite's json_extract as a bound expression parameter. The attacker manipulates the JSONPath grammar, rather than injecting SQL commands.
What CVE-2026-77846 Can Expose?
The AshSqlite vulnerability becomes relevant when an application permits untrusted input to reach get_path/2, such as through a public calculation, filter, or API that lets callers select JSON fields.A normal endpoint might permit a caller to request a top-level title field. However, supplying private.secret can cause AshSqlite to generate $.private.secret, allowing traversal into a nested object that the API was never intended to expose. Malformed input, such as an unbalanced bracket or bare $, can also produce SQLite JSON path errors that reveal information about the underlying structure.The published proof of concept used AshSqlite 0.2.17, Bandit, and Req. It created a JSON record containing {"title":"hello","private":{"secret":"s3cr3t-api-key-9f2c"}}. A benign key=title request returned hello, while key=private.secret returned s3cr3t-api-key-9f2c. Captured SQL showed json_extract(p0."data", ?) with the parameter $.private.secret, confirming the traversal. The PoC concluded that a single attacker-controlled path segment could leak a nested value through an endpoint designed to expose only top-level keys.
Fixes and Administrator Actions for CVE-2026-77846
The fix replaces the unsafe path joining with encoding that represents keys safely, escapes backslashes and quotes, and handles numeric array indexes separately. Administrators should upgrade to AshSqlite 0.2.18 or later and audit applications that accept network-controlled field-selection input.Until upgrades are completed, applications should restrict dynamic get_path/2 calls to predefined names, reject dangerous path characters such as periods and brackets, and avoid exposing arbitrary JSON paths.After upgrading, dependency locks and deployment images should be checked for older ash_sqlite versions. Logs should also be reviewed for unusual dots, brackets, or JSONPath symbols in field-selection requests. Such requests do not prove exploitation, but can help identify systems requiring investigation.The practical risk of CVE-2026-77846 depends on application architecture. Internal applications without untrusted callers face lower exposure, while public search, filtering, and field-selection APIs require careful validation and access controls.
A newly disclosed GitLab vulnerability has revealed how two long-standing memory-safety flaws in the widely used Ruby JSON parsing library, Oj, can be combined to achieve remote code execution on default GitLab installations.
The research, led by Yuhang Wu as part of the Open Defense Initiative, demonstrates how attackers could exploit Jupyter Notebook file processing to execute arbitrary commands, potentially exposing repositories, application secrets, and internal services.
Yuhang Wu Disco
A newly disclosed GitLab vulnerability has revealed how two long-standing memory-safety flaws in the widely used Ruby JSON parsing library, Oj, can be combined to achieve remote code execution on default GitLab installations.The research, led by Yuhang Wu as part of the Open Defense Initiative, demonstrates how attackers could exploit Jupyter Notebook file processing to execute arbitrary commands, potentially exposing repositories, application secrets, and internal services.
Yuhang Wu Discovers GitLab Vulnerability in Oj Parser
As part of the Open Defense Initiative, Depthfirst researcher Yuhang Wu used an automated analysis system to examine Oj, a high-performance native C-based JSON parser used across Ruby applications, including GitLab. The analysis identified 18 prioritised vulnerabilities, seven of which were memory-safety issues. Two of these flaws had remained undetected for nearly five years before being combined into a working exploit chain.The vulnerabilities included an unchecked nesting-stack write in Oj::Parser.usual.parse and an unsafe 16-bit key-length narrowing issue that leaked a heap pointer. Individually, the bugs appeared limited, offering only a repeated one-byte write primitive and a fixed 29-byte memory disclosure. However, by carefully manipulating heap allocation, the exploit gained control of a callback pointer and bypassed Address Space Layout Randomisation (ASLR), enabling arbitrary code execution as the "git" system user.
Jupyter Notebook Processing Creates Attack Path
The GitLab vulnerability stems from the platform's handling of Jupyter Notebook (.ipynb) files. GitLab uses an in-tree gem called ipynbdiff to generate human-readable notebook differences. Before displaying a diff, the gem parses each notebook with Oj to verify that the JSON contains a "cells" field.Because Jupyter Notebook files are JSON documents, any authenticated user with permission to push commits and view commit differences could submit specially crafted notebook files. The exploit chain used two malicious notebook files in a single commit-diff request. The first abused excessive nesting depth to corrupt an internal buffer pointer, eventually allowing a Ruby Array to overlap with a parser callback pointer and overwrite p->start with an attacker-controlled address.The second file leaked a heap pointer through an oversized JSON object key that appeared in the generated HTML diff. This disclosed the memory addresses of libraries such as libc and libruby, defeating ASLR. Since GitLab's Puma application server processes multiple threads using a shared parser instance, both files were handled by the same vulnerable parser, allowing the corrupted callback to invoke system() and execute shell commands.Unlike previous GitLab remote code execution vulnerabilities that depended on server-side request forgery (SSRF) against Redis, this GitLab vulnerability bypassed modern SSRF protections by targeting a native memory-unsafe dependency within Ruby code. Any project member with standard push and diff-view permissions could trigger the attack without administrator privileges, CI/CD access or user interaction. According to Depthfirst, successful exploitation could expose repository source code, Rails secrets, service credentials, and internal services, creating risks of data theft, code tampering, and lateral movement.
Affected Versions and Available Fixes
The GitLab vulnerability affects GitLab CE/EE versions 15.2.0-18.10.7, fixed in 18.10.8; 18.11.0-18.11.4, fixed in 18.11.5; and 19.0.0-19.0.1, fixed in 19.0.2. The Oj gem is affected from versions 3.13.0-3.17.1 and fixed in version 3.17.3.GitLab.com had already been patched before disclosure, while GitLab Dedicated customers required no action. Self-managed deployments running affected versions should upgrade immediately. The vulnerable Oj code was introduced in August 2021, with GitLab adopting the affected parser in July 2022 through version 15.2.0. Yuhang Wu reported the Oj flaws on 21 May 2026 after they had remained undiscovered for 1,753 days. Oj merged fixes on 27 May, released version 3.17.3 on 4 June, and the GitLab exploit chain was reported on 5 June, confirmed on 8 June and patched on 10 June 2026 in releases 19.0.2, 18.11.5 and 18.10.8. The same research also uncovered nine additional published CVEs affecting Oj, including stack and heap buffer overflows, use-after-free vulnerabilities, a negative-size memcpy flaw and a large-file integer overflow, highlighting the risks posed by memory-unsafe native extensions in Ruby applications.
Entrar
