Last updated: August 19, 2026 at 1:47 AM UTC
All 741 Vulnerability 286 Breach 129 Threat 319 Defense 7

Anthropic MCP STDIO design flaw exposes 200,000+ AI servers to RCE - 14 CVEs assigned, Anthropic calls it 'expected behavior' (backfill from April 15)

Backfill from April 15: OX Security disclosed an architectural flaw in the official Model Context Protocol SDKs (Python, TypeScript, Java, Rust) that lets attacker-controlled JSON config trigger arbitrary OS commands via the STDIO transport. Roughly 200,000 publicly reachable MCP servers and 150 million SDK downloads inherit the issue. OX has tied 14 CVEs to the same root cause across LiteLLM (patched), Bisheng (patched), Windsurf (zero-click RCE in Cursor-style IDEs, still reported), Flowise, LangFlow, GPT Researcher, Agent Zero, and DocsGPT. Anthropic declined to patch the protocol, calling the behavior 'expected.'

Check
Audit every MCP server installed in Claude Code, Cursor, and other AI dev tools, remove any whose origin you don't recognize, and treat MCP configs as executable code.
Affected
Any tool or service running an Anthropic-SDK MCP server with STDIO transport, especially when add/configure flow is exposed to user input or marketplaces. Confirmed-affected: LiteLLM, LangChain, LangFlow, Flowise, LettaAI, LangBot, DocsGPT, Bisheng, Windsurf, Cursor IDE workflows, GPT Researcher, plus any private MCP server built on the official SDK without input sanitization.
Fix
Patch downstream tools to fixed versions (LiteLLM, Bisheng, Cursor). Block public internet access to services that host MCP add/configure UIs. Treat all external MCP configuration input as untrusted; never let raw user input reach StdioServerParameters. Run MCP services in sandboxes with no production-secret access. Install MCP servers only from verified sources and pin to specific commits.

A small Discord group quietly accessed Anthropic's most powerful AI hacking tool 'Mythos' for two weeks via a contractor account (backfill from April 21)

Backfill from April 21: Anthropic confirmed an unauthorized Discord group quietly accessed Mythos - the company's most powerful AI cybersecurity tool, restricted to about 40 vetted partners including Apple, Microsoft, and Google. The group got in on the same day Mythos was announced (April 7) by piggybacking on a member who works at one of Anthropic's third-party contractors, then guessed the model's URL based on naming patterns from previously leaked information. Anthropic says the group used Mythos to build websites, not for attacks - but they had quiet access for two weeks. Mozilla used Mythos to find and patch 271 Firefox bugs.

Check
If you're a Project Glasswing partner, audit which contractor environments have access to Mythos and rotate any credentials they used since April 7.
Affected
Anthropic Project Glasswing partners (about 40 organizations including Apple, Microsoft, Google, Mozilla, Cisco) and their downstream contractors. Any organization granting AI tool access to third-party contractors without isolation - the same naming-pattern guess works if your past internal models have been leaked, making new models' URLs predictable.
Fix
For partners: rotate all credentials any contractor environment used to reach Mythos, audit Mythos query logs for unfamiliar patterns, segment contractor access from production AI tooling. For everyone: assume new AI tool URLs that follow your existing naming convention are guessable, randomize URL paths for restricted models, and treat third-party contractor accounts as a primary attack surface.

Microsoft ships emergency out-of-band updates to fix Windows Server reboot loops and install failures caused by April Patch Tuesday

Microsoft has released out-of-band emergency updates to fix two Windows Server issues introduced by the April 2026 Patch Tuesday updates. First issue: some admins experienced failures installing the KB5082063 security update on Windows Server 2025. Second issue: Patch Tuesday cumulative updates caused Windows servers running domain controller roles to enter restart loops due to crashes of the Local Security Authority Subsystem Service (LSASS). The restart loop can also hit newly-set-up domain controllers or existing ones if the server processes authentication requests very early during startup. The Windows Server 2025 OOB update (KB5091157) addresses both issues. OOB updates for other supported Windows Server versions address only the domain controller restart issue. This is the third consecutive year where April Windows Server patches have caused authentication-related breakage, following similar incidents in 2024 and 2025.

Check
If you run Windows Server domain controllers and installed April Patch Tuesday updates, apply the OOB fix before your DCs enter the restart loop.
Affected
Windows Server domain controllers that installed the April 2026 Patch Tuesday updates, particularly in Privileged Access Management (PAM) environments and non-Global Catalog DC configurations. Windows Server 2025 systems that had failures installing KB5082063.
Fix
Apply the out-of-band update for your Windows Server version. For Windows Server 2025, install KB5091157, which addresses both the install failure and the DC restart loop. For other supported Server versions, install the matching OOB update from Microsoft's advisory (addresses the DC restart loop only). If you have servers already in a restart loop, boot into safe mode or recovery mode to apply the OOB update before normal startup triggers another LSASS crash. Also check for the separate BitLocker recovery key prompt issue on Windows Server 2025 after KB5082063 - keep BitLocker recovery keys accessible before patching.

Mexican cybersecurity firm BePrime breached because admin accounts had no MFA - 12.6 GB leaked including pentest reports, then BePrime threatened journalists who reported it

On April 20 a threat actor using the alias 'dylanmarly' posted 12.6 GB of stolen data from Mexican cybersecurity firm BePrime, claiming compromise of admin accounts that had no MFA enabled. The dump includes plaintext credentials, financial transaction records, security audit and pentest reports detailing client vulnerabilities, plus API keys for 1,858 Cisco Meraki network devices and live surveillance camera feeds. Affected clients include Iberdrola (Spanish energy giant), ArcelorMittal, Whirlpool, and Alsea (Latin American operator of Starbucks, Domino's, Vips). BePrime then announced legal action against journalists reporting on it.

Check
If you use any managed security service provider, confirm in writing this week that they enforce phishing-resistant MFA on every admin account holding your credentials or API keys.
Affected
BePrime's enterprise clients - Iberdrola, ArcelorMittal, Whirlpool, Alsea, Vitro, and others operating in Mexico and Latin America - face direct downstream risk because the leak includes pentest reports identifying their unpatched weaknesses and Meraki API keys with operational control over their network devices.
Fix
BePrime clients should rotate every shared credential, Meraki API key, and integration token immediately and audit Meraki configs for unauthorized changes since March 2026. Cut or sandbox network trusts to BePrime infrastructure pending review. For all organizations: add MFA-enforcement attestation to vendor security questionnaires and put contractual breach-notification SLAs in place for every MSP with privileged access.

Vercel confirms breach - attackers got in through Context.ai AI tool's Google Workspace OAuth, stole customer environment variables

Cloud development platform Vercel disclosed a security incident on April 19 after a threat actor claiming to be ShinyHunters posted stolen data for sale on a hacking forum. Vercel CEO Guillermo Rauch confirmed the initial access came through a breach at Context.ai, an enterprise AI platform one Vercel employee had signed up for using their Vercel enterprise account with 'Allow All' OAuth permissions. Attackers compromised Context.ai, stole the OAuth token, took over the employee's Google Workspace account, and pivoted into Vercel environments. Once inside, they accessed environment variables not marked as 'sensitive' - these are stored unencrypted at rest, unlike sensitive env vars which Vercel encrypts. The attacker posted 580 employee records (names, emails, account status, activity timestamps) as a teaser, plus screenshots of an internal Vercel Enterprise dashboard. They claim to also have access keys, source code, database data, and API keys, though Vercel characterizes impact as a 'limited subset' of customers. Mandiant is engaged. This is the cleanest real-world example to date of the AI supply chain risk pattern everyone has been warning about: a third-party AI tool with broad OAuth scopes becomes the initial access vector into your primary infrastructure.

Check
If you deploy apps on Vercel, rotate all environment variables immediately - especially any not marked 'sensitive'. Also audit every third-party AI/SaaS tool that has OAuth access to your Google Workspace or similar identity provider.
Affected
Any Vercel customer with environment variables not marked 'sensitive'. Vercel has directly contacted a 'limited subset' of customers whose credentials were compromised. If you weren't contacted, Vercel says it has no evidence of your data being accessed at this time. Separately: any organization using Context.ai with Google Workspace OAuth granted 'Allow All' permissions.
Fix
Rotate every Vercel environment variable and redeploy applications to pick up the new values. Mark any secret as 'sensitive' in Vercel's dashboard going forward - this encrypts at rest. In Google Workspace Admin, search for and revoke OAuth App ID 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com. Review Google Workspace audit logs between April 1-19 for unusual OAuth grants or token access. Audit every third-party tool connected to your Google Workspace - specifically those granted broad OAuth scopes - and remove any your team isn't actively using.

Critical protobuf.js RCE hits JavaScript ecosystem - 50M weekly npm downloads, PoC published (GHSA-xq3m-2v4x-88gg)

Security firm Endor Labs disclosed a critical remote code execution flaw in protobuf.js, a widely used JavaScript implementation of Google's Protocol Buffers with nearly 50 million weekly downloads on npm. The bug lets attackers achieve RCE when an application loads a malicious protobuf schema. Root cause: protobuf.js builds JavaScript functions from protobuf schemas by concatenating strings and executing them via the Function() constructor, but doesn't validate schema-derived identifiers like message names. An attacker can supply a crafted schema that injects arbitrary JavaScript into the generated function, which then runs when the app processes any message using that schema. This opens access to environment variables, credentials, databases, and internal systems - plus lateral movement within infrastructure. Developer machines are also at risk if they load and decode untrusted schemas locally. The flaw has a proof-of-concept exploit in Endor Labs' advisory and 'exploitation is straightforward' per the researchers, but no in-the-wild exploitation has been observed yet. No official CVE assigned - tracked as GHSA-xq3m-2v4x-88gg. Reported March 2 by Cristian Staicu, patched on GitHub March 11, npm patches released April 4 (8.x branch) and April 15 (7.x branch).

Check
Audit your JavaScript and Node.js codebases plus transitive dependencies for protobuf.js. If you run any service that deserializes protobuf messages, treat this as urgent.
Affected
protobuf.js versions 8.0.0 and earlier on the 8.x branch, and 7.5.4 and earlier on the 7.x branch. The library is used for inter-service communication, real-time applications, and structured data storage in databases and cloud environments. Any app that loads attacker-influenced protobuf schemas is at risk - this includes services accepting schemas from users, partners, or untrusted registries.
Fix
Upgrade to protobuf.js 8.0.1 (8.x branch) or 7.5.5 (7.x branch). Check your package.json and package-lock.json for both direct and transitive dependencies - protobuf.js is often pulled in by other packages. For defense-in-depth per Endor Labs' guidance: treat schema-loading as untrusted input, prefer precompiled or static schemas in production, and audit transitive dependencies that may still pin an older protobuf.js version even after you upgrade your direct dependency.

Microsoft April patches cause reboot loops on Windows Server 2025 and 2022 domain controllers - LSASS crash breaks authentication

Microsoft has confirmed that the April 2026 cumulative updates (KB5082063 for Windows Server 2025, KB5082142 for Windows Server 2022) are causing LSASS crashes that trigger reboot loops on non-Global Catalog domain controllers in environments using Privileged Access Management (PAM). Affected DCs restart repeatedly, preventing authentication and directory services from functioning, potentially rendering the entire domain unavailable. The issue also occurs when setting up new domain controllers or on existing ones processing authentication requests early in startup. A separate bug causes the April update to fail installation entirely on some Windows Server 2025 systems with error code 0x800F0983. A third issue forces some servers into BitLocker recovery mode due to Secure Boot changes bundled in the update. This is the third consecutive year April Patch Tuesday has broken Windows Server authentication - similar LSASS/domain controller issues hit in April 2024 and April 2025.

Check
If you run Active Directory and use Privileged Access Management (PAM), do NOT deploy the April 2026 updates to domain controllers without Microsoft mitigation guidance.
Affected
Non-Global Catalog (non-GC) domain controllers on Windows Server 2025 (KB5082063), Windows Server 2022 (KB5082142), Server 23H2, Server 2019, and Server 2016, specifically in environments using Privileged Access Management (PAM). Consumer Windows devices are not affected.
Fix
Hold deployment of the April 2026 cumulative update on affected domain controllers. Contact Microsoft Support for Business to access the official mitigation - it can be applied both before and after the April update. Microsoft is working on a permanent fix in a future Windows update. For BitLocker recovery issues: ensure you have recovery keys accessible before patching. Non-DC member servers and workstations should still be patched on schedule to close the zero-day vulnerabilities (SharePoint CVE-2026-32201, Defender CVE-2026-33825) covered in our April 15 report.

13-year-old Apache ActiveMQ code injection flaw actively exploited - CISA gives federal agencies until April 30 to patch (CVE-2026-34197)

A critical code injection flaw in Apache ActiveMQ Classic has been under active exploitation in the wild, and CISA added it to the Known Exploited Vulnerabilities catalog on April 16 with a federal patch deadline of April 30. The flaw, tracked as CVE-2026-34197 (CVSS 8.8), has been 'hiding in plain sight' for 13 years according to Horizon3.ai researcher Naveen Sunkavally. The vulnerability is in the Jolokia JMX-HTTP bridge exposed at /api/jolokia/. An attacker can send crafted HTTP requests with a malicious discovery URI that forces the broker to load a remote Spring XML configuration. Because Spring initializes beans before validation, attackers execute arbitrary OS commands via Runtime.exec() - effectively turning a messaging broker into a remote command runner. Fortinet FortiGuard Labs telemetry shows exploitation attempts peaking on April 14, 2026. SAFE Security reports threat actors actively scanning for exposed Jolokia management endpoints.

Check
Inventory every ActiveMQ instance in your environment. If you don't know whether you run ActiveMQ, check with your dev team - it's embedded in many enterprise messaging pipelines and IoT data flows.
Affected
Apache ActiveMQ Classic versions 5.x before 5.19.4, and 6.0.0 before 6.2.3. The vulnerable component is the Jolokia JMX-HTTP bridge exposed via the web console at /api/jolokia/. Any internet-exposed ActiveMQ broker with default Jolokia configuration is at risk.
Fix
Upgrade to Apache ActiveMQ 5.19.4 or 6.2.3. If you cannot patch immediately: block external access to the /api/jolokia/ endpoint at your firewall or reverse proxy, restrict the Jolokia policy to specific MBeans only (not the default org.apache.activemq:* wildcard), and require authentication for all management operations. Check your access logs for HTTP requests to /api/jolokia/ with suspicious URI parameters over the past 30 days - exploitation requires only one successful request.

NIST stops enriching most new CVEs - only KEV-listed and federal-used software will get full NVD data going forward

NIST has announced major changes to how the National Vulnerability Database processes new CVEs, driven by a 263% surge in submissions that the agency can no longer keep up with. As of April 15, 2026, NIST will only provide full enrichment (CVSS scoring, CWE mapping, CPE identification) for CVEs that meet specific criteria: vulnerabilities in the CISA KEV catalog, those in software used by the federal government, and a small set of other priority categories. Everything else remains listed in the NVD but without the detailed metadata that security teams rely on for automated patch prioritization. Dustin Childs at ZDI noted during Patch Tuesday coverage that AI-driven vulnerability discovery has tripled his own triage volume. The same pressure is hitting NIST. Practical impact: vulnerability management tools, automated scanners, and patch prioritization workflows that depend on NVD enrichment data will have blind spots for the majority of new CVEs. Private vulnerability intelligence feeds (VulnCheck, Tenable, Qualys) become more important for anyone who relied on NVD as the single source of truth.

Check
Review how your vulnerability management program depends on NVD data. If your scanner or SIEM pulls CVSS scores and CPE data directly from NVD, many new CVEs will return incomplete results.
Affected
Any organization relying primarily on NVD as a vulnerability intelligence source. Automated patch prioritization tools, SIEM integrations, asset management platforms, and compliance reporting that map CVEs to systems via CPE identifiers will have coverage gaps for non-KEV, non-federal-priority CVEs.
Fix
Layer additional vulnerability intelligence sources on top of NVD. Consider subscribing to VulnCheck KEV (expanded exploitation data), CISA KEV directly (smaller but authoritative), or commercial feeds from Tenable, Qualys, or Rapid7. For patch prioritization, weight exploitation evidence (KEV listing, public PoC, threat intel reports) more heavily than CVSS scores alone - since many new CVEs won't have CVSS scores at all. Review your vulnerability SLAs - 'patch all criticals within N days' policies need rewording if criticality can't be automatically determined from NVD.

Fortinet FortiSandbox unauthenticated RCE (CVE-2026-39808) has public PoC - day-after recovery from April 17

Day-after recovery: a PoC exploit for a critical vulnerability in Fortinet's FortiSandbox product has been publicly available since April 17. CVE-2026-39808 allows an unauthenticated attacker to execute arbitrary code on affected appliances via the web management interface. FortiSandbox is Fortinet's network-based malware analysis product used to inspect suspicious files before they reach endpoints. Because it sits in the malware analysis path, a compromised FortiSandbox gives attackers visibility into every suspicious file your environment has flagged, including real phishing attempts and incident samples. The PoC release doesn't indicate confirmed in-the-wild exploitation yet, but based on recent patterns the window between public PoC and mass scanning is typically measured in hours. CISA has not yet added this to KEV.

Check
If your organization uses Fortinet FortiSandbox, apply Fortinet's security update immediately. Treat as priority-1 even without confirmed in-the-wild exploitation.
Affected
Fortinet FortiSandbox appliances running unpatched firmware. Check Fortinet's PSIRT advisory for CVE-2026-39808 for exact affected firmware versions and upgrade paths for your model.
Fix
Apply Fortinet's security update from the official PSIRT advisory. If patching is delayed, restrict network access to the FortiSandbox management interface to trusted admin IPs only - do not expose the management interface to the internet. Review FortiSandbox access logs for unusual HTTP requests to the management interface over the past 30 days.