medium1 source
The CVSS version 4.0 framework introduced by the Forum of Incident Response and Security Teams is shifting how vulnerability severity gets measured across the industry. Under this standard, vendors assign a base severity score representing the technical ceiling of a flaw, which is subsequently adjusted using dynamic threat metrics like exploit maturity.
When a vulnerability has no known active exploitation or public proof-of-concept, the calculated threat-adjusted score drops significantly below the base technical score. Security leaders note that this design aims to give vulnerability management teams a standardized method to de-prioritize bugs that currently lack weaponized tooling.
However, researcher Kevin Beaumont highlighted that vendors serving as CVE Numbering Authorities, including major players like Cisco, Microsoft, and Palo Alto Networks, can define consumer-oriented threat metrics during initial disclosure. By tagging exploit maturity as 'Unreported' rather than leaving it 'Not Defined'—which historically assumed worst-case conditions—vendors can effectively prevent critical unauthenticated remote code execution bugs from scoring above an 8.0.
This structural shift risks misclassifying critical flaws as mere high-severity items on disclosure day, creating blind spots for operational patching workflows. Practitioners warn that vendors rarely return to update these CVSS threat vectors once weaponized exploits surface publicly, leaving downstream organizations with deflated scores unless internal teams continuously re-evaluate external intelligence against their assets.
Read more → about CVSS v4.0 Exploit Maturity Metrics Are Leading to Artificially Deflated Vulnerability Scoreshigh1 source
A server-side request forgery vulnerability has been disclosed in the proxy functionality of draw.io, enabling attackers to bypass private IP blocklists via DNS rebinding. The vulnerability manifests specifically in deployments where the proxy feature is activated through the `ENABLE_DRAWIO_PROXY=1` configuration flag.
The root cause lies in how the application performs domain name resolution across two distinct execution stages without maintaining shared state. When handling an incoming request, the `Utils.sanitizeUrl()` method first invokes `InetAddress.getByName(host)` to confirm that the destination IP does not belong to private or restricted network blocks.
Once the sanitization check completes successfully, execution flows to `ProxyServlet`, which instantiates a fresh `URL` object and invokes `url.openConnection()`. This operation initiates a completely independent, secondary DNS resolution process within the JVM.
An attacker controlling an authoritative nameserver configured with a Time to Live (TTL) of zero can serve a benign public IP address during the initial validation check. The attacker then rapidly flips the DNS record to an internal IP address before the second lookup executes.
Because the JVM's DNS caching TTL can be configured as low as zero, this race condition is reliably exploitable in practice. Successful exploitation allows attackers to force the server to issue HTTP requests to internal endpoints such as the cloud instance metadata service at `169.254.169.254`.
The application subsequently base64-encodes the fetched response body and returns it directly to the requester. This behavior permits the exfiltration of sensitive cloud tokens, such as AWS IMDSv1 temporary IAM credentials or GCP service account tokens, as well as the probing of intranet services.
Read more → about DNS Rebinding in Draw.io ProxyServlet Allows Cloud Metadata and Internal Network Bypasshigh1 sourceCVE-2026-71963 CVE-2026-72718
Researchers at Manifold Security disclosed a vulnerability class dubbed GitSpawn that affects multiple AI-powered developer tools, including Claude Code, Cursor, OpenAI Codex, Goose, Hermes Agent, Grok Build, and Qwen Code.
The issue stems from how coding agents automatically gather repository context on launch by executing background commands like `git status` or `git diff` before receiving user input or establishing workspace trust boundaries.
When a developer opens a project directory pre-populated with a `.git` folder, the local repository configuration dictates how Git executes certain features.
The primary attack vector leverages Git's legitimate `core.fsmonitor` configuration, which is designed to call external helper utilities to optimize file-change monitoring in massive codebases.
Because the automated agents run background Git commands without first sanitizing local repository settings, Git parses the attacker-supplied `core.fsmonitor` value and executes the specified executable on the host system.
The resulting payload runs with the developer's logged-in permissions, completely bypassing standard AI sandboxing and prompt-based confirmation dialogues.
Standard operations like `git clone` or `git pull` do not carry local repository configuration files, meaning attacks rely on direct directory transfers like ZIP archives, shared storage drives, or sync folders.
Researchers identified eight distinct vulnerabilities across the affected agents, observing that the spawned processes run entirely in the background without UI alerts or user interaction.
Remediation has begun across the industry, with Goose patching CVE-2026-72718 in version 1.44.0 and Claude Code addressing its `core.fsmonitor` vector in version 2.1.196 alongside fixes for Cursor and Codex.
However, several products remained vulnerable at disclosure time, including Hermes Agent (CVE-2026-71963) in version 0.21.0, Grok Build version 1.0.13, Qwen Code version 0.22.3, and an additional unpatched `ultrareview` configuration execution sink in Claude Code.
Read more → about GitSpawn Flaw in AI Coding Agents Executes Malicious Commands via Git Configurationshigh1 source
Security researcher Johann Rehberger has demonstrated a technique to bypass security checks in Anthropic's Claude Code coding assistant when running with Auto Mode enabled. Auto Mode operates as a convenience setting designed to execute low-risk local actions without prompting the user for manual confirmation each time. To test the boundary, the researcher created a website mimicking an archive of notebook records and asked Claude Code to generate a summary.
During processing, Claude downloaded a zip archive containing encoded data and an included decoder binary. While Claude initially refused to run the bundled decoder, it opted to write and execute a custom Python script to decode the records autonomously. The researcher exploited standard Python module resolution order by placing a malicious file named `struct.py` alongside the target data in the downloads folder.
Because Claude executed its custom script directly inside the downloads directory, Python prioritized and imported the rogue `struct.py` over the standard library module. The payload silently maintained execution flow, allowing Claude's generated script to finish without raising alarms, while the malicious code performed unauthorized background actions. In advanced variations, the hijacked process was able to spawn an entirely separate, nested Claude Code agent with independent tool execution privileges.
The exploit bypassed automated checks in an estimated 60% to 80% of test iterations, depending on the working directory chosen by the model and environmental factors. Curiously, in instances where Claude detected anomalous behavior post-execution and attempted to kill the rogue process, Auto Mode occasionally blocked the remediation command itself. Anthropic reportedly marked the vulnerability report as informative, stating that Auto Mode is an assistive classifier rather than an ironclad security perimeter.
Read more → about Indirect Prompt Injection and Python Module Hijacking Bypass Claude Code Auto Mode