Back to Blog
CVE-2026-39987 Marimo Python Notebook vulnerability on Strobes platform showing CVSS 9.8, Priority Score 819, EPSS 55%

Top 7 Critical CVEs of April 2026 You Need to Act On Now

Shubham JhaMay 1, 202622 min read

Table of Contents

Authors

S
Shubham Jha

Share

88% of organizations had the patch. 88% did not apply it.

That is the story running underneath every critical CVE of April 2026, and it is not a comfortable one. These were not sophisticated operations requiring elite tooling or nation-state budgets. They required an unpatched system and an attacker willing to show up before your team did.

One crew stole credentials from a data science server in under ten hours. A ransomware group was already operating inside enterprise endpoint management before the vulnerability even had a name. GitHub infrastructure sat exposed for seven weeks while developers pushed code through it every single day.

The gap between knowing something is broken and actually fixing it is where breaches live. This month, that gap was wide open.

Here is the full breakdown of the top CVEs of April 2026. For context on how CISA and NIST have changed their approach to tracking and prioritizing these disclosures, see our post on how NIST just changed CVE prioritization.

CVEs covered: 6 | Added to CISA KEV: 5 | Fastest time to exploit: 9h 41m | Vendors affected: 4

April 2026 at a glance

CVE Product CVSS Exploited CISA KEV Fix
CVE-2026-39987Marimo Python Notebook9.3Yes, 9h 41mApr 23v0.23.0
CVE-2026-33824Windows IKE Extensions9.8No (high risk)NoKB5083769
CVE-2026-35616Fortinet FortiClient EMS9.1Yes, zero-dayApr 6Hotfix
CVE-2026-34621Adobe Acrobat and Reader8.6YesApr 13APSB26-43
CVE-2026-3854GitHub Enterprise Server8.7Yes, 88% unpatchedNoGHES 3.19.3
CVE-2026-34197Apache ActiveMQ Classic8.8YesApr 165.19.4 / 6.2.3
CVE-2026-21643Fortinet FortiClient EMS9.1Yes, pre-patchApr 13Fortinet patch

01. CVE-2026-39987: Marimo Pre-Authentication Remote Code Execution

Marimo Python Notebook · Disclosed April 9, 2026

CVSS v4.0: 9.3 Critical | CISA KEV: April 23, 2026 | Exploited in 9 hours 41 minutes | No authentication required | Fixed in: v0.23.0

Why this made the list

Marimo runs inside data science environments that sit next to production secrets, cloud tokens, and ML pipelines. An unauthenticated shell on one of these hosts is not a web application compromise. It is a cloud credential compromise. This is the kind of actively exploited CVE that does not look catastrophic until you think about what is running next to the vulnerable server.

The missing authentication check

Marimo's terminal endpoint at /terminal/ws skipped the same validate_auth() check that every other sensitive WebSocket endpoint on the server correctly enforced. Any attacker who could reach the server over the network received a full interactive PTY shell with no credentials required, no exploit code needed, and no user interaction involved. The root cause is CWE-306: Missing Authentication for Critical Function.

Unlike other WebSocket endpoints on the same server, such as /ws, the terminal endpoint only checked whether the server was running in edit mode and whether the platform supported PTY before accepting connections. Authentication was skipped entirely. The fix in version 0.23.0 adds the missing validate_auth() call to the terminal endpoint handler.

CVE-2026-39987 Marimo Python Notebook vulnerability on Strobes platform showing CVSS 9.8, Priority Score 819, EPSS 55%, Trend Rising
CVE-2026-39987 on the Strobes Vulnerability Intelligence platform: CVSS 9.8, Priority Score 819/1000, EPSS 55%, Trend Rising.

Attack scenario

The attacker scans for internet-exposed Marimo instances using standard asset discovery tools and connects directly to /terminal/ws without credentials. They receive a full interactive shell running as the user who started the Marimo process. From there, they read .env files, SSH keys, cloud tokens, and database credentials stored in the notebook environment.

The Sysdig Threat Research Team observed exactly this sequence in their honeypot infrastructure: credential theft was completed in under three minutes. The attacker returned an hour later to check whether other threat actors were also active on the same host. Between April 11 and 14, 2026, Sysdig recorded 662 exploit events targeting this vulnerability from 11 unique source IPs across 10 countries. A later exploitation wave deployed NKAbuse, a multi-platform malware that abuses the NKN peer-to-peer protocol for command and control.

Why the blast radius here is bigger than 9.3 suggests

CVSS 9.3 is technically accurate but practically incomplete. The severity depends almost entirely on what sits next to your Marimo instance. In most data science environments, that means production API keys, cloud IAM credentials, and database connection strings with five-figure monthly spend caps attached. A single compromised Marimo host in a well-connected ML environment is not a server compromise. It is a cloud account takeover.

Remediation

Immediate: Update to Marimo 0.23.0, which properly implements validate_auth() on the terminal WebSocket endpoint.

Workaround: Block external access to /terminal/ws at your network layer or reverse proxy before patching is complete.

Detect: Hunt for WebSocket connections to /terminal/ws from unexpected source IPs. Flag any session where the terminal endpoint was accessed without a preceding authenticated session on the same host. Look for new child processes spawned from the Marimo process, outbound connections to unexpected destinations, and credential-access activity on affected hosts.

02. CVE-2026-33824: Windows IKE Service Extensions Remote Code Execution

Microsoft Windows · April 14, 2026 (Patch Tuesday)

CVSS v3.1: 9.8 Critical | No authentication required | Affects: Windows 10, 11, Server 2019 and later | Fixed in: KB5083769

Why this made the list

IKE is the handshake engine behind most enterprise VPNs. It is exposed to untrusted networks by design and processes unauthenticated traffic as part of normal operation. A working exploit against it means initial access to the network edge without touching a single credential. Every organization running Always On VPN, site-to-site tunnels, or Windows-based remote access infrastructure is within scope for this critical vulnerability in the April 2026 Patch Tuesday release.

The memory corruption in the VPN handshake

A double-free memory error (CWE-415) in the Windows IKEv2 extension. An attacker sends specially crafted fragment packets to any Windows machine with IKEv2 enabled. The IKEEXT service processes these packets before any authentication occurs, which is how IKE is designed to work as part of the IPsec negotiation process. The double-free corrupts memory in a way that can lead to arbitrary code execution. No user interaction is required. The vulnerability affects the IKE Service Extensions component specifically, not the broader IPsec stack.

Attack scenario

The attacker scans for IKEv2-exposed Windows systems on UDP ports 500 and 4500, which are standard ports for corporate VPN infrastructure and routinely findable via internet scanning. Specially crafted IKE fragment packets trigger the double-free and can crash or hijack the IKEEXT service, achieving remote code execution on the VPN gateway. From the gateway, the attacker sits at the highest-value position in the network: the edge device that every remote employee trusts to tunnel them inside the corporate environment. Lateral movement from this position can reach everything behind the perimeter.

Why "exploitation less likely" does not mean ignore

Microsoft flagged this as "Exploitation Less Likely" at time of release. That designation reflects exploit complexity at the moment of patching, not the long-term risk profile. Historic IKE vulnerabilities have been weaponized in targeted campaigns against network infrastructure by nation-state actors. Organizations with exposed IKE services and delayed patch cycles should treat this critical vulnerability as high priority regardless of the initial exploitation likelihood flag. The CVSS score of 9.8 reflects the worst case accurately. The Microsoft flag reflects only the current state of known tooling.

Remediation

Immediate: Apply KB5083769 for Windows 11 24H2/25H2, or the corresponding April 2026 Patch Tuesday update for your specific Windows version across all Windows 10, 11, and Server editions.

Workaround: Block inbound UDP 500 and 4500 at the perimeter firewall for systems that do not require IKE. For systems that do require IKE, restrict inbound traffic on those ports to known peer addresses only.

Detect: Monitor for IKEEXT service crashes, unexpected service restarts, or anomalous IKEv2 fragment traffic patterns in your network perimeter logs. Alert on any unexpected outbound connections originating from IKEEXT service processes.

03. CVE-2026-35616: Fortinet FortiClient EMS Pre-Auth API Access Bypass

Fortinet FortiClient EMS · CISA KEV: April 6, 2026

CVSS v3.1: 9.1 Critical | Zero-day | No authentication required | Affected versions: EMS 7.4.5 through 7.4.6 | Hotfix: Available

Why this made the list

This is the second critical unauthenticated vulnerability in FortiClient EMS in a matter of weeks. That pattern is not random. It signals that attackers have studied this product's attack surface in depth and that each patch is being followed immediately by a hunt for what it did not cover. If you run FortiClient EMS and it is reachable from the internet, April 2026 should be the month that changes that permanently.

The API layer that skipped access control

Improper access control (CWE-284) in the FortiClient EMS API layer. The vulnerability allows an unauthenticated attacker to send crafted requests that bypass both authentication and authorization checks entirely, then execute arbitrary code or commands on the EMS server. The issue sits in the API interface itself rather than in any specific feature or endpoint, which is why partial mitigation without removing internet exposure is not sufficient. Affected versions are FortiClient EMS 7.4.5 through 7.4.6. Exploitation was first recorded in watchTowr honeypots on March 31, 2026, before the patch existed.

Attack scenario

An attacker identifies an internet-exposed FortiClient EMS instance using Shodan or similar reconnaissance platforms. Using the API access bypass, they execute code on the EMS server, which is the system responsible for managing endpoint security policies across the entire managed endpoint fleet. From this position, the attacker can modify endpoint security group configurations, disable protection on target machines, or push malicious content through the legitimate EMS agent update channel. One server compromised can mean every managed endpoint in the organization is exposed. Exploitation attempts were already in the wild before the CVE was publicly disclosed, confirming this was a zero-day at the time of active exploitation.

Why two CVEs in the same product in one month changes the calculus

This is the second critical unauthenticated bug in FortiClient EMS in consecutive weeks. Organizations should not treat this as an isolated patch event. The frequency of critical flaws in a single product in a short time window signals sustained, focused research by threat actors who have made this product a priority target. Patching CVE-2026-35616 while CVE-2026-21643 remains unpatched, or vice versa, leaves your vulnerability management program with a false sense of closure. Both need to be addressed together, and the broader question of internet exposure for this management plane needs a permanent answer.

Remediation

Immediate: Apply the Fortinet out-of-band hotfix for FortiClient EMS 7.4.5 and 7.4.6 immediately. Do not defer to the next maintenance window.

Workaround: Remove FortiClient EMS from public internet exposure and restrict access to trusted internal network ranges only before patching is complete.

Detect: Review EMS logs for new administrator accounts created outside normal change management windows, unexpected API call patterns, and modifications to endpoint security group policies not initiated through your standard processes.

04. CVE-2026-34621: Adobe Acrobat and Reader Prototype Pollution RCE

Adobe Acrobat and Reader · CISA KEV: April 13, 2026

CVSS v3.1: 8.6 High | Actively exploited | User interaction required | Affected: Acrobat DC up to 24.001.30356, Reader DC up to 26.001.21367 | EPSS: 8.00%

Why this made the list

Adobe Acrobat Reader is installed on hundreds of millions of endpoints across every industry. One malicious PDF opened by one employee is all this vulnerability requires. That combination of massive install base, phishing-friendly delivery mechanism, and confirmed active exploitation in the wild makes this one of the most reliable and widely deployed attack vectors among the critical CVEs of April 2026.

The prototype pollution in the PDF engine

Adobe Acrobat's JavaScript engine improperly controls modification of object prototype attributes (CWE-1321). In JavaScript, every object inherits from a prototype. If an attacker can manipulate that prototype, they can alter the behavior of all objects of that type at runtime. A crafted PDF injects attacker-controlled logic into the prototype chain. When Acrobat's engine processes the document, it executes the injected code at the privilege level of the Acrobat process. Adobe initially scored this at CVSS 9.6 and later revised to 8.6 after adjusting the attack vector from Network to Local. The vulnerability affects Acrobat DC up to version 24.001.30356 and Acrobat Reader DC up to version 26.001.21367 on both Windows and macOS.

CVE-2026-34621 Adobe Acrobat Reader prototype pollution vulnerability on Strobes platform showing CVSS 8.6, Priority Score 631, EPSS 8%
CVE-2026-34621 on the Strobes Vulnerability Intelligence platform: CVSS 8.6, Priority Score 631/1000, EPSS 8.0%, affecting Apple macOS, Microsoft Windows, and Adobe Acrobat.

The Strobes Vulnerability Intelligence platform shows CVE-2026-34621 with a Priority Score of 631 out of 1000, an EPSS of 8.00%, public exploits confirmed available, and patches released. Affected products include Adobe Acrobat DC and Adobe Acrobat Reader DC on both Windows and macOS.

Attack scenario

A threat actor crafts a malicious PDF and delivers it via phishing email to a target employee. The victim opens the file in Adobe Acrobat Reader. Prototype pollution executes attacker code at the Acrobat process privilege level without any secondary interaction. The payload drops a loader, establishes persistence through a registry run key or scheduled task, and begins credential harvesting or beaconing to a command and control server. In environments where Acrobat Reader is deployed across thousands of endpoints, even a modest phishing open rate results in a meaningful number of compromised machines.

Why CVSS 8.6 still means patch immediately

The score dropped from 9.6 to 8.6 due to a technical adjustment in the attack vector. That adjustment does not change the operational reality. Phishing campaigns routinely achieve significant open rates against targeted organizations, Acrobat Reader is the default PDF handler on most corporate endpoints, and this vulnerability is already being actively exploited. The Strobes Priority Score of 631 and the CISA KEV listing both reflect a patch-now classification, not a schedule-for-maintenance one. The user interaction requirement is not a meaningful barrier when that interaction is opening a PDF, which employees do dozens of times a day.

Remediation

Immediate: Update Adobe Acrobat and Reader via Help, then check for updates. Enterprise deployments can use AIP-GPO, bootstrapper, or SCUP/SCCM on Windows.

Workaround: Disable JavaScript in Acrobat preferences under Edit, then Preferences, then JavaScript, by unchecking Enable Acrobat JavaScript. This removes the prototype pollution execution path while patching is rolled out.

Detect: Monitor Acrobat processes for unusual child process spawning, specifically cmd.exe, powershell.exe, or wscript.exe launched as children of Acrobat Reader. Flag any Acrobat process initiating outbound network connections to unexpected external addresses.

05. CVE-2026-3854: GitHub Enterprise Server Remote Code Execution via Git Push

GitHub Enterprise Server · Publicly disclosed April 28, 2026

CVSS v3.1: 8.7 Critical | Authenticated (any push access) | Affects: GHES all versions before 3.19.3 | Fixed in: GHES 3.19.3

Why this made the list

GitHub Enterprise Server is where your source code lives, your CI/CD pipelines run, and your deployment secrets are stored. CVE-2026-3854 meant any developer with push access to any repository could execute arbitrary commands on that infrastructure with a single standard git push. Not a custom exploit. Not a crafted binary. A command every developer runs dozens of times a day.

The command injection in the babeld proxy

GitHub's internal git infrastructure routes every push through a proxy called babeld, which forwards metadata to backend services via an internal HTTP header called X-Stat. User-supplied push option values were not sanitized before being inserted into that header. Because the header uses semicolons as delimiters between security-critical configuration fields, an attacker could inject additional fields by including semicolons in crafted push option values. Wiz Research chained three injections to achieve unsandboxed code execution: bypassing the sandbox via a forged rails_env value, redirecting hooks via custom_hooks_dir, and executing arbitrary commands as the git user via a crafted repo_pre_receive_hooks entry. The root cause is CWE-74: Improper Neutralization of Special Elements in Output Used by a Downstream Component.

Attack scenario

The attacker creates a repository on the target GHES instance, which requires only a standard user account, then runs a git push with crafted push option values containing injected semicolons. The babeld proxy inserts the unsanitized values into X-Stat, overriding security-critical configuration fields and achieving unsandboxed code execution as the git user on the backend. From that position, the attacker has full filesystem read and write access across the entire GHES instance, including all hosted source code, CI/CD configurations, deployment keys, webhook secrets, and internal service credentials. GitHub.com was patched within 75 minutes of Wiz's report on March 4, 2026. At public disclosure on April 28, 2026, Wiz's data showed 88% of self-hosted GHES instances remained unpatched, meaning the majority of organizations running their own GitHub infrastructure were still vulnerable nearly two months after a fix was available.

Why 88% unpatched after 49 days is the real story here

GitHub.com was fixed in 75 minutes. The GHES patch shipped on March 10, 2026. Public disclosure came on April 28. Organizations had 49 days to apply a patch before details went public, and 88% of them had not done it. Developer infrastructure consistently gets treated as a lower patching priority than production servers and security appliances, despite holding credentials, source code, and pipeline access that rivals any other system in the environment in terms of attacker value. Wiz also noted this is one of the first critical vulnerabilities in closed-source binaries discovered using AI-assisted analysis, which signals that discovery speed against complex multi-service architectures is about to increase significantly.

Remediation

Immediate: Upgrade GitHub Enterprise Server to version 3.19.3 or later. Fixes are available for all supported GHES versions from v3.14 through v3.20. GitHub.com and all GitHub-hosted cloud offerings are already patched and require no action.

Workaround: No partial mitigation exists short of upgrading. Restricting push access to trusted users only reduces the attack surface but does not eliminate it.

Detect: Review /var/log/github-audit.log on your GHES instance for push operations containing semicolons in push option values. A semicolon in a push option is not normal and should be treated as a compromise indicator. Alert on unexpected outbound connections from GHES backend processes and audit recent changes to hook configurations or rails_env values across the instance.

06. CVE-2026-34197: Apache ActiveMQ Classic Code Injection via Jolokia API

Apache ActiveMQ Classic · CISA KEV: April 16, 2026

CVSS v3.1: 8.8 High | Authenticated (low privilege) | EPSS: 60% | Affected: before 5.19.4, from 6.0.0 before 6.2.3 | Fixed in: 5.19.4 or 6.2.3

Why this made the list

ActiveMQ sits at the centre of enterprise data pipelines across financial services, healthcare, logistics, and e-commerce. Exploitation of this vulnerability does not just compromise a server. It compromises the message bus connecting dozens of downstream services. The underlying behavior enabling this flaw had existed in the codebase for approximately 13 years, which means any unpatched or legacy ActiveMQ deployment in your environment is a live target right now.

The 13-year-old Jolokia exposure

Apache ActiveMQ Classic exposes the Jolokia JMX-HTTP bridge at /api/jolokia/ on its web console. The default Jolokia access policy permits execution operations on all ActiveMQ MBeans, including BrokerService.addNetworkConnector(). An authenticated attacker invokes this operation with a crafted discovery URI that triggers the VM transport's brokerConfig parameter to load a remote Spring XML application context. Because Spring's ResourceXmlApplicationContext instantiates all singleton beans before the BrokerService validates the configuration, arbitrary code execution occurs on the broker's JVM through bean factory methods such as Runtime.exec(). This behavior has been present in the codebase since approximately 2013. Affected versions are Apache ActiveMQ Classic before 5.19.4 and from 6.0.0 before 6.2.3. ActiveMQ Artemis is not affected.

Attack scenario

The attacker identifies an internet-exposed ActiveMQ instance with the Jolokia management endpoint accessible. Using web console credentials, which in many environments remain at the default admin/admin, they send a crafted request to /api/jolokia/ invoking the addNetworkConnector operation with a URI containing a brokerConfig parameter pointing to an attacker-controlled Spring XML configuration file. ActiveMQ fetches the file and executes the embedded commands as the broker process user. The attacker now has code execution inside the enterprise messaging infrastructure, with direct access to queue contents, connected databases, and every downstream service consuming from those queues. Fortinet FortiGuard Labs recorded exploitation activity peaking on April 14, 2026, the same day as Patch Tuesday, a timing pattern consistent with threat actors monitoring patch releases to identify newly disclosed targets.

Why 8.8 with default credentials is effectively unauthenticated

This vulnerability requires authenticated access to the ActiveMQ web console. That sounds like a meaningful barrier. In practice, it is not. In a significant portion of enterprise ActiveMQ deployments, the default credentials of admin/admin remain unchanged because ActiveMQ is treated as internal infrastructure rather than a security perimeter. The EPSS score of 60% reflects how aggressively this is already being scanned and exploited in the wild. On versions 6.0.0 through 6.1.1, combining this CVE with CVE-2024-32114 removes the authentication requirement entirely, creating a fully unauthenticated RCE chain. The practical exploitability of this vulnerability is considerably higher than CVSS 8.8 suggests for any organization running default credentials.

Remediation

Immediate: Upgrade Apache ActiveMQ Classic to version 5.19.4 or 6.2.3. Change all default web console credentials across every ActiveMQ deployment in your environment as a parallel action, not a follow-up.

Workaround: Disable the Jolokia endpoint entirely or restrict it to localhost only via the ActiveMQ configuration. Block external access to the ActiveMQ web console.

Detect: Monitor requests to /api/jolokia/ for invocations of addNetworkConnector or addConnector with parameters referencing external URIs. Alert on any outbound HTTP or HTTPS connections initiated by the ActiveMQ broker process to unexpected external hosts, which is the tell-tale sign of the remote configuration fetch pattern of this exploit.

07. CVE-2026-21643: Fortinet FortiClient EMS SQL Injection

Fortinet FortiClient EMS · CISA KEV: April 13, 2026

CVSS v3.1: 9.1 Critical | No authentication required | Linked threat actor: Storm-1175 | Ransomware: Medusa

Why this made the list

Storm-1175 was observed weaponizing related Fortinet flaws to deliver Medusa ransomware during this same period. CVE-2026-21643 is not an isolated disclosure. Together with CVE-2026-35616, it represents a sustained, systematic targeting campaign against FortiClient EMS infrastructure across April 2026. Two critical unauthenticated vulnerabilities in the same product in the same month is a pattern that warrants more than routine patching. It warrants a structural review of how your organization exposes security management infrastructure to the internet. The Strobes VI platform now tracks threat actors including Storm-1175 and their active campaigns in real time.

The unauthenticated SQL injection

An unauthenticated SQL injection vulnerability (CWE-89) in FortiClient EMS. An attacker sends specially crafted HTTP requests that inject arbitrary SQL commands into the underlying database query without any prior authentication. The injected commands execute against the EMS database and lead to arbitrary command execution on the server. Exploitation attempts targeting this flaw were detected from March 24, 2026, weeks before the patch was publicly available, confirming threat actors had identified and were actively using this vulnerability before it was disclosed to defenders.

CVE-2026-21643 Fortinet FortiClient EMS SQL injection vulnerability on Strobes platform showing CVSS 9.8, Priority Score 819, EPSS 43%
CVE-2026-21643 on the Strobes Vulnerability Intelligence platform: CVSS 9.8, Priority Score 819/1000, EPSS 43.0%, zero-day with active exploits, linked to Storm-1175 and Medusa ransomware.

Attack scenario

Storm-1175 identifies an exposed FortiClient EMS instance and exploits the SQL injection for initial code execution on the EMS server. Using that foothold, they create backdoor administrator accounts for persistence and modify endpoint security group policies to disable protection on target machines. With those defenses lowered, Medusa ransomware is pushed to the managed endpoint fleet through the legitimate EMS management channel, the same channel your security team uses to deploy policy updates. By the time encryption begins, the attacker has typically been operating inside the management plane for several hours. The attack is particularly effective because it uses the trusted management infrastructure against itself.

Why a named ransomware group changes the priority entirely

The confirmed involvement of Storm-1175 actively deploying Medusa ransomware through this CVE places it in a different category from a vulnerability that is merely severe on paper. When a specific threat actor with a documented ransomware operation is already using a vulnerability as part of their kill chain, the question for your vulnerability management program is not whether this warrants attention. It is whether you are patched before the next campaign wave. Ransomware operators do not move on after a patch is released. They accelerate their campaigns during the window between disclosure and broad patch adoption, targeting organizations they know are likely to be behind on patching.

Remediation

Immediate: Apply the Fortinet security patch and immediately audit all FortiClient EMS administrator accounts for any unauthorized entries created in the past 30 days. Treat any account you cannot account for as a backdoor.

Workaround: Restrict EMS access to internal networks only and block all external access to the management interface while patching is underway.

Detect: Check EMS logs for SQL error patterns alongside unexpected database queries, new admin account creation outside change management windows, unexpected endpoint policy group modifications, and any EMS-initiated outbound connections not part of normal operation.

What April 2026 is really telling you

Attackers did not pick a lane this month. They hit Python notebooks, VPN gateways, endpoint management platforms, message brokers, and developer infrastructure all in the same 30 days. That is not a coincidence. That is a strategy.

The top CVEs of April 2026 exposed something the security industry keeps dancing around. CVSS scores are not a prioritization strategy. A zero-day was exploited before it had a patch number. A ransomware operation was already running through endpoint management before defenders knew the CVE existed. A fix sitting available for 49 days that 88% of organizations never touched. A vulnerability marked as authenticated that was effectively open to anyone because nobody had changed the default credentials.

A severity score tells you what a vulnerability could do in theory. It tells you nothing about what attackers are doing with it right now.

That gap is where organizations got hurt this month, and it is exactly what the Strobes Vulnerability Intelligence platform is built to close. Live EPSS scores, real-time exploit availability, affected product mapping, and Strobes Priority Scores that reflect actual risk rather than a number assigned at the time of disclosure. Every top CVE of April 2026 is tracked live, with context that actually helps your team move faster than the threat.

Stop triaging from a spreadsheet. Start here at strobes.co/vi.

See also