Search: discovery.com

CISA's Binding Operational Directive (BOD) 26-04 changes federal vulnerability management by ending reliance on static severity scores and mandating a dynamic, risk-based prioritization model based on asset exposure, KEV status, exploit automation, and technical impact. Tenable One provides continuous asset discovery, threat validation, and automated orchestration to help federal agencies comply with these requirements. The directive enforces compressed remediation timelines for vulnerabilities on internet-facing assets with known exploitation and total control impact, requiring forensic triage within three days. Tenable's platform integrates CISA's KEV catalog and offers early warnings for emerging threats, enabling proactive remediation. The directive requires continuous monitoring as compliance timelines shift with changes in risk variables. Tenable's research identifies high-risk vulnerabilities not yet listed on KEV, providing predictive prioritization to reduce risk beyond compliance.

A large-scale compromise of over 75,000 Fortinet device administrator credentials has been reported. The compromised credentials appear to be recent and include devices that are still online. The data was reportedly obtained from device configuration exports, containing sensitive information visible only from the devices themselves. This incident affects a significant portion of Fortinet firewall devices exposed to the internet, estimated at around 15% based on Shodan polling. The compromised devices include many with fairly recent patches. The source of this information is a Reddit post linking to a LinkedIn profile of a security researcher involved in the discovery.

Vulnerability in the Oracle Enterprise Manager Base Platform product of Oracle Enterprise Manager (component: Discovery Framework). Supported versions that are affected are 13.5 and 24.1. Easily exploitable vulnerability allows low privileged attacker with network access via HTTPS to compromise Oracle Enterprise Manager Base Platform. While the vulnerability is in Oracle Enterprise Manager Base Platform, attacks may significantly impact additional products (scope change). Successful attacks of this vulnerability can result in takeover of Oracle Enterprise Manager Base Platform. CVSS 3.1 Base Score 9.9 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H).

Discover how continuous control validation in Tenable One can improve your CTEM program by filtering out alert noise and factoring in your active cyber defenses. Focus your team on accessible and exploitable attack paths. Key takeaways: With vulnerability exploitation ranking as the top initial access vector and frontier AI accelerating vulnerability discovery, organizations must shift from managing theoretical cyber risks to validating actual, accessible exposure. Tenable One maps active security controls including EDR, MFA, and firewalls directly onto potential attack paths, allowing teams to automatically deprioritize weaknesses that existing defenses already neutralize. Ingesting penetration testing results via the Tenable One Open Connector allows organizations to layer real-world attack simulations over real-time exposure insights to identify toxic risk combinations that threaten critical assets. Your security tools probably indicate you have thousands, perhaps tens or hundreds of thousands, of vulnerabilities across your environment. Maybe your tools prioritize these vulnerabilities based on CVSS scores or other criteria, but how do you know which vulnerabilities combine with other preventable security risks, like misconfigured cloud buckets and identity weaknesses, to create attack paths threat actors could realistically traverse? How do you validate which vulnerabilities an existing security control mitigates? You need this context to distinguish the real risks from the theoretical ones to ensure your team focuses on remediating what matters most. The work of validating, prioritizing, and remediating vulnerabilities alongside other security weaknesses to understand the true exposure they create has become much more urgent, as frontier AI models accelerate vulnerability discovery. In this environment, the traditional patch-based defense model will get crushed. Moreover, defenders cannot afford inaccurate decision-making and wasted remediation work that addresses low-priority vulnerabilities. They desperately need the context and validation that a continuous threat exposure management (CTEM) program provides. This is why security leaders are evolving their vulnerability management programs to exposure management programs. Exposure management allows you to continually assess your attack surface, prioritize risks , and orchestrate automated remediation of security weaknesses at machine speed. Exposure management also helps validate which exposures attackers can actually reach by understanding the accessibility and exploitability of an attack path. It uses validation to shift your organization from managing theoretical risks to executing on actual exposure. What is exposure validation in CTEM? Validation is one of the five steps in the CTEM lifecycle. It is the process of providing consistent, continuous, and automated evidence of an attack’s feasibility. It stress-tests your defenses against real-world attack conditions, using your own environment’s controls and configurations to confirm whether an exposure is genuinely reachable and exploitable. Validation moves security from a reactive “patch everything” mindset to a preemptive, evidence-based exposure strategy . It continuously confirms which weaknesses your existing defenses have already blocked and surfaces the ones that demand immediate attention. Expanded CTEM validation capabilities in Tenable One Validation isn’t new to Tenable: we’ve been using validation techniques in Tenable solutions for more than 25 years. Tenable developed nearly 3,000 direct check plugins to actively probe a vulnerability and prove its exploitability in situations where software version detection isn’t sufficient for our high-accuracy standards. These plugins actually mimic attack techniques and monitor the target’s response to confirm the presence of the vulnerability. What is new in Tenable One is the addition of continuous control validation in the platform. By factoring in your active security controls, Tenable One helps eliminate the noise of theoretically exposed assets that are functionally blocked from exploitation. Security teams can visually map their active prevention and detection controls directly onto potential attack paths, automatically prioritizing weaknesses that existing controls already neutralize. Analysts can also filter top attack paths based on the presence of security controls and whether you can prevent attack chains for faster triage and investigation. Common control validation examples include: Endpoint detection and response (EDR) tools that block Local Security Authority Subsystem Service (LSASS) memory dump tools used to harvest credentials. Multi-factor authentication (MFA) methods that prevent unauthorized access via password guessing , password spraying , or credential stuffing . Firewall and data loss prevention (DLP) tools that prevent data exfiltration by detecting data staging and enforcing egress rules. See how continuous control validation works in Tenable One. Proactively manage risk prioritization with continuous security control validation. Eliminate noise from theoretical risks that are functionally blocked by existing defenses by integrating compensating security controls into the exposure prioritization process. Access a unified dashboard where assets, vulnerabilities, and exposure risks are consolidated. Filter attack paths to identify which are protected by compensating controls. View types of compensating controls deployed in the environment. Examine attack paths that could be protected with endpoint protection tools. Review security controls associated with specific attack paths, including SIEM and EDR controls. Inspect individual nodes within attack paths to determine which security controls are protecting them. Identify assets monitored by SIEM tools such as Splunk. Verify endpoint protection coverage on assets, including Microsoft Defender installations. Filter attack techniques to focus on specific threats like LSASS Memory techniques, which extract credentials from compromised systems and can be mitigated by endpoint protection tools. Identify attack paths and assets lacking appropriate EDR coverage. Prioritize remediation by examining high-priority attack paths where compensating controls are absent. Collaborate with security control owners to confirm coverage and address gaps in protection for critical assets. Integrate penetration testing data into Tenable One Beyond direct check plugins and continuous control validation, security teams can also integrate penetration testing results into Tenable One that simulate real-world attacks against your cyber defenses. This is another way to validate which exposures are truly exploitable and contextualizes them against your broader attack surface. The Tenable One Open Connector makes it easy to ingest the latest pentest results and layer them with real-time exposure insights to turn your findings into active, continuous defenses. Integrating pentest data into an exposure management program adds critical context to help you understand toxic risk combinations and enrich your understanding of high-severity weaknesses that threaten your most critical business assets. Context is essential in exposure management In the AI era, your security team can’t waste precious time on the wrong issues. With exposure management, context is essential to pinpoint the most critical risks to your organization. Security control validation, coupled with asset criticality, threat activity, entitlement privileges, and attack pathways, give your security team the advantage it needs to stay ahead of threat actors. Learn more about Tenable One , the exposure management platform for the modern attack surface.

CISA issued BOD 26-04, which replaces BOD 22-01 with a four-variable vulnerability prioritization model requiring federal agencies to patch the most dangerous vulnerabilities in as few as three days. Key takeaways BOD 26-04 replaces BOD 22-01 with a four-variable risk model that assigns graduated remediation timelines, from as few as three days with mandatory forensic triage for the most dangerous vulnerabilities to full deferral for the lowest-risk ones, ending the era of flat, one-size-fits-all patching deadlines for federal agencies. The transition represents a significant operational lift at a time when AI is compressing the window between vulnerability disclosure and weaponization, and industry remediation rates are declining: only 26% of KEV vulnerabilities were fully remediated in 2025 according to the 2026 Verizon DBIR, down from 38% the prior year. Organizations that have invested in continuous asset discovery, risk-based prioritization, and exposure management are well positioned to operationalize the directive’s four-variable model. Those still relying on periodic scanning and CVSS-based prioritization face a significant gap between current capability and compliance requirements. Background on CISA BOD 26-04 On June 10, 2026, the Cybersecurity and Infrastructure Security Agency (CISA) issued Binding Operational Directive (BOD) 26-04, “Prioritizing Security Updates Based on Risk.” BOD 26-04 represents a fundamental shift in how federal agencies are expected to manage vulnerabilities. Rather than treating every known exploited vulnerability (KEV) with the same remediation deadline, the new directive introduces a graduated model that accounts for asset exposure, exploitation evidence, adversary automation capability, and technical impact severity. The result is a 16-tier remediation matrix where the most dangerous vulnerabilities must be patched within three days (with mandatory forensic triage), while lower-risk vulnerabilities can be deferred to the next system upgrade cycle. Tenable applauds this directive, which replaces both BOD 22-01 (Reducing the Significant Risk of Known Exploited Vulnerabilities, November 2021) and BOD 19-02 (Vulnerability Remediation Requirements for Internet-Accessible Systems, April 2019). It is directionally correct in Tenable’s view, and it represents a significant improvement upon its predecessors, as it consolidates seven years of federal vulnerability remediation policy into a single, risk-weighted framework. More importantly, it aligns with the risk-based, exposure-driven approach to vulnerability management that Tenable has championed as the originator of the exposure management paradigm. For years, Tenable has maintained the position that defenders must move beyond volume-based patching toward intelligent prioritization grounded in real-world exploitation evidence, asset context, and threat actor intelligence. BOD 26-04 codifies that position as federal policy. Frequently asked questions about BOD 26-04 What is BOD 26-04? BOD 26-04 is a binding operational directive from CISA that requires all Federal Civilian Executive Branch (FCEB) agencies to prioritize vulnerability remediation based on a four-variable risk model. Unlike its predecessor BOD 22-01, which assigned flat remediation timelines to all vulnerabilities in the KEV catalog, BOD 26-04 evaluates each vulnerability against four criteria and assigns a remediation deadline based on the specific combination of risk factors present. The directive is mandatory for federal agencies but not for the private sector. However, CISA explicitly encourages private sector adoption, and the track record of BOD 22-01 suggests the framework will become a de facto standard across industries. BOD 22-01’s KEV catalog is already used by organizations worldwide as a prioritization signal, and BOD 26-04’s more sophisticated model will likely follow the same adoption curve. What are the four variables? BOD 26-04 determines remediation urgency using four binary variables: Publicly exposed - Is the vulnerable asset reachable from outside the agency network via a routable IP address? This is the only variable agencies must determine themselves. In the KEV - Is the CVE listed in CISA’s Known Exploited Vulnerabilities catalog? This confirms real-world exploitation. Automatable by adversary - Can an attacker automate all the steps necessary to exploit the vulnerability? This assesses weaponization maturity. Technical impact - Does exploitation give attackers total control of the affected system or only partial control? CISA publishes the answers to variables two, three, and four for every CVE through its Vulnrichment Program. Agencies must determine variable one (public exposure) using their own asset inventory and CISA’s Internet Exposure Reduction Guidance. What are the remediation timelines? Table 1 in Appendix A of the directive maps all 16 possible combinations of the four binary variables to specific remediation deadlines across five tiers: Three days with forensic triage - Required when a vulnerability is in the KEV and yields total system control (regardless of whether the asset is publicly exposed or the exploit is automatable). This is the most aggressive vulnerability management timeline in federal directive history. The forensic triage component requires agencies to assess whether their systems have already been compromised. Three days (without forensic triage) - Required for certain high-risk combinations, such as a publicly exposed asset with an automatable vulnerability yielding total control, even if the CVE is not yet in the KEV. 14 days - The standard accelerated timeline for most KEV-listed vulnerabilities and several high-risk non-KEV combinations. 60 days - Applied to lower-risk combinations, such as non-exposed assets with automatable but partial-control vulnerabilities. Fix on system upgrade - Applied when no risk criteria are met. This is the deferral tier, and it represents a significant operational relief for agencies: vulnerabilities that meet none of the four criteria can wait for the next scheduled upgrade cycle. Timelines are dynamic. If an agency removes a system from public internet exposure, the applicable timeline shifts to a longer window. Conversely, if CISA adds a vulnerability to the KEV catalog, the remediation timeline accelerates immediately. In an initial analysis at one large civilian agency, CISA found that only 1% of vulnerability instances fell into the three-day category, while over 60% qualified for deferral to the next system upgrade. The model is designed to focus resources, not overwhelm them. What changed from BOD 22-01? BOD 26-04 revokes and replaces BOD 22-01 entirely. The key differences are substantial: BOD 22-01 applied a flat remediation timeline to every vulnerability in the KEV catalog (14 days for CVEs assigned after 2021, six months for older CVEs). BOD 26-04 replaces this with a graduated model where KEV status is one of four variables, not the sole determinant of urgency. A KEV vulnerability on an internal system with partial control and no automation capability now receives 14 days, while the same KEV on a publicly exposed system with full automation and total control receives just three days with mandatory forensic triage. BOD 22-01 had no deferral mechanism. Every KEV required action. BOD 26-04 introduces the “fix on system upgrade” tier for vulnerabilities that meet none of the four risk criteria, allowing agencies to focus on the ones that matter most rather than chasing every vulnerability with equal urgency. BOD 22-01 had no forensic triage requirement. BOD 26-04 introduces mandatory forensic analysis for the highest-risk tier, recognizing that when a vulnerability is actively exploited and yields total system control, patching alone is insufficient: organizations need to determine whether they’ve been compromised. The underlying methodology also shifts. BOD 22-01 relied primarily on the KEV catalog and CVSS scoring. BOD 26-04 is informed by CISA’s Stakeholder-Specific Vulnerability Categorization (SSVC) system, which provides a more nuanced, risk-informed vulnerability analysis methodology. Why did CISA issue BOD 26-04 now? Two converging factors drove the directive. The first is the deteriorating effectiveness of traditional vulnerability management. Citing the 2026 Verizon Data Breach Investigations Report, CISA’s blog post accompanying the directive notes that only 26% of KEV-listed vulnerabilities were fully remediated by organizations in 2025, a decline from 38% the previous year. Meanwhile, the median time to fully resolve vulnerabilities rose to 43 days. In an environment where exploitation can occur within hours of disclosure, the remediation gap is widening. The second factor is artificial intelligence. CISA explicitly states that AI is accelerating both vulnerability discovery and weaponization, narrowing the window of time that exists between vulnerability disclosure and exploitation. The directive aligns with priorities in the recent AI Executive Order , Promoting Advanced Artificial Intelligence Innovation and Security . As AI-enabled tools make it easier for adversaries to identify, weaponize, and deploy exploits at scale, the traditional “patch everything eventually” approach becomes untenable. Defenders need a framework that tells them what to patch first, and BOD 26-04 provides the framework enabling them to prioritize on an accelerated timeframe. This is a challenge Tenable has been tracking closely. The intersection of an AI-enabled threat landscape with already-declining remediation effectiveness creates a compounding problem: adversaries are getting faster while defenders fall farther behind. BOD 26-04 is a necessary policy response to this environment. I don’t work for a federal agency. How does BOD 26-04 affect my organization? While BOD 26-04 is mandatory only for FCEB agencies, its influence extends well beyond the federal government. BOD 22-

CVE-2026-53473 is a cross-site scripting (XSS) vulnerability in migration-planner-ui-app that allows an attacker to register a malicious discovery agent with a crafted credentialUrl containing JavaScript code. When an organizational user clicks this link, the malicious script executes in the user's browser, compromising their Red Hat Single Sign-On (SSO) session. This can lead to unauthorized cross-tenant data access and API actions. The vulnerability affects versions prior to 0.13.5 and has a high severity rating with a CVSS score of 7.3.

Anthropic's Mythos Preview was highly effective at finding vulnerability candidates, especially when analyzing source code. XBOW explores how the model performed across exploit discovery, reverse engineering, and live-site validation. [...]

In the Linux kernel, the following vulnerability has been resolved: nvmet: avoid recursive nvmet-wq flush in nvmet_ctrl_free nvmet_tcp_release_queue_work() runs on nvmet-wq and can drop the final controller reference through nvmet_cq_put(). If that triggers nvmet_ctrl_free(), the teardown path flushes ctrl->async_event_work on the same nvmet-wq. Call chain: nvmet_tcp_schedule_release_queue() kref_put(&queue->kref, nvmet_tcp_release_queue) nvmet_tcp_release_queue() queue_work(nvmet_wq, &queue->release_work) <--- nvmet_wq process_one_work() nvmet_tcp_release_queue_work() nvmet_cq_put(&queue->nvme_cq) nvmet_cq_destroy() nvmet_ctrl_put(cq->ctrl) nvmet_ctrl_free() flush_work(&ctrl->async_event_work) <--- nvmet_wq Previously Scheduled by :- nvmet_add_async_event queue_work(nvmet_wq, &ctrl->async_event_work); This trips lockdep with a possible recursive locking warning. [ 5223.015876] run blktests nvme/003 at 2026-04-07 20:53:55 [ 5223.061801] loop0: detected capacity change from 0 to 2097152 [ 5223.072206] nvmet: adding nsid 1 to subsystem blktests-subsystem-1 [ 5223.088368] nvmet_tcp: enabling port 0 (127.0.0.1:4420) [ 5223.126086] nvmet: Created discovery controller 1 for subsystem nqn.2014-08.org.nvmexpress.discovery for NQN nqn.2014-08.org.nvmexpress:uuid:0f01fb42-9f7f-4856-b0b3-51e60b8de349. [ 5223.128453] nvme nvme1: new ctrl: NQN "nqn.2014-08.org.nvmexpress.discovery", addr 127.0.0.1:4420, hostnqn: nqn.2014-08.org.nvmexpress:uuid:0f01fb42-9f7f-4856-b0b3-51e60b8de349 [ 5233.199447] nvme nvme1: Removing ctrl: NQN "nqn.2014-08.org.nvmexpress.discovery" [ 5233.227718] ============================================ [ 5233.231283] WARNING: possible recursive locking detected [ 5233.234696] 7.0.0-rc3nvme+ #20 Tainted: G O N [ 5233.238434] -------------------------------------------- [ 5233.241852] kworker/u192:6/2413 is trying to acquire lock: [ 5233.245429] ffff888111632548 ((wq_completion)nvmet-wq){+.+.}-{0:0}, at: touch_wq_lockdep_map+0x26/0x90 [ 5233.251438] but task is already holding lock: [ 5233.255254] ffff888111632548 ((wq_completion)nvmet-wq){+.+.}-{0:0}, at: process_one_work+0x5cc/0x6e0 [ 5233.261125] other info that might help us debug this: [ 5233.265333] Possible unsafe locking scenario: [ 5233.269217] CPU0 [ 5233.270795] ---- [ 5233.272436] lock((wq_completion)nvmet-wq); [ 5233.275241] lock((wq_completion)nvmet-wq); [ 5233.278020] *** DEADLOCK *** [ 5233.281793] May be due to missing lock nesting notation [ 5233.286195] 3 locks held by kworker/u192:6/2413: [ 5233.289192] #0: ffff888111632548 ((wq_completion)nvmet-wq){+.+.}-{0:0}, at: process_one_work+0x5cc/0x6e0 [ 5233.294569] #1: ffffc9000e2a7e40 ((work_completion)(&queue->release_work)){+.+.}-{0:0}, at: process_one_work+0x1c5/0x6e0 [ 5233.300128] #2: ffffffff82d7dc40 (rcu_read_lock){....}-{1:3}, at: __flush_work+0x62/0x530 [ 5233.304290] stack backtrace: [ 5233.306520] CPU: 4 UID: 0 PID: 2413 Comm: kworker/u192:6 Tainted: G O N 7.0.0-rc3nvme+ #20 PREEMPT(full) [ 5233.306524] Tainted: [O]=OOT_MODULE, [N]=TEST [ 5233.306525] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org 04/01/2014 [ 5233.306527] Workqueue: nvmet-wq nvmet_tcp_release_queue_work [nvmet_tcp] [ 5233.306532] Call Trace: [ 5233.306534] <TASK> [ 5233.306536] dump_stack_lvl+0x73/0xb0 [ 5233.306552] print_deadlock_bug+0x225/0x2f0 [ 5233.306556] __lock_acquire+0x13f0/0x2290 [ 5233.306563] lock_acquire+0xd0/0x300 [ 5233.306565] ? touch_wq_lockdep_map+0x26/0x90 [ 5233.306571] ? __flush_work+0x20b/0x530 [ 5233.306573] ? touch_wq_lockdep_map+0x26/0x90 [ 5233.306577] touch_wq_lockdep_map+0x3b/0x90 [ 5233.306580] ? touch_wq_lockdep_map+0x26/0x90 [ 52 ---truncated---

On June 2, 2026, the White House signed an Executive Order directing federal agencies to harden their systems with AI-enabled cyber defenses and to stand up a new AI cybersecurity clearinghouse — most of it on a 30-day clock. Here’s what the EO requires and how Tenable can help. Key takeaways: The new AI Security Executive Order will require national security and civilian federal agencies to prioritize cyber defenses to account for new frontier AI model capabilities. Tenable is well positioned to help federal agencies gain visibility across their environments, including AI assets, and to prioritize the vulnerabilities and other exposures that pose the highest risk; Tenable AI-enabled exposure management capabilities can help support vulnerability remediation and automate multi-step remediation workflows. The vulnerability and patching clearinghouse which will be developed under the Executive Order will require strong engagement from private sector partners, including Tenable, to drive actionable insights on AI-associated vulnerabilities and mitigation prioritization. On June 2, 2026, the President signed an Executive Order (EO) titled “ Promoting Advanced Artificial Intelligence Innovation and Security .” The direction is clear and the calls to action are fast-moving. Within 30 days: Federal agencies must begin hardening their information systems with AI-enabled cyber defenses. CISA must issue new directives or guidance for civilian agencies. The Department of the Treasury (Treasury), with the National Security Agency (NSA) and the Cybersecurity and Infrastructure Security Agency (CISA), must stand up a new AI cybersecurity clearinghouse focused on finding and fixing software vulnerabilities. Within 60 days, Treasury, with the Department of War (DoW), NSA and CISA, in consultation with the White House and other agencies, must establish a classified benchmarking process to assess the capabilities of frontier AI models through voluntary collaboration with AI developers. While the Executive Order applies to U.S. federal agencies, the need to prepare for changes in the threat landscape brought about by the advanced cyber capabilities of frontier AI models applies to any organization that needs to manage cyber risk. Here’s a breakdown of what the AI EO requires, the deadlines that matter, and where Tenable fits. What the AI Executive Order requires The EO’s operative provisions sit in Section 2 (“Upgrading American systems for advanced AI”) and Section 3 (“Secure frontier model deployment”). The cybersecurity core is in Section 2. Within 30 days: National security and defense systems. The Committee on National Security Systems must prioritize the cyber defense of National Security Systems (NSS) and the Secretary of War must do the same for DoW information systems (Section 2(a) and 2(b)). Civilian federal systems and critical infrastructure. CISA, in consultation with the Office of Management and Budget (OMB), the Assistant to the President for National Security Affairs, and the National Cyber Director, must release Binding Operational Directives (BODs) “and other guidance as appropriate” to: Expedite and prioritize the cyber defense of civilian federal information systems. Establish or expand federal programs and services that enhance AI-enabled defensive tools. Facilitate access to cybersecurity tools and services, including where appropriate, covered frontier models, for agencies, state and local authorities, and critical infrastructure operators such as rural hospitals, community banks, and local utilities. Worth noting, while the EO directs CISA to release BODs or other guidance for federal civilian agencies, the specific implementation directives are not yet known (Section 2(c)). The AI cybersecurity clearinghouse. The Secretary of the Treasury, with the National Cyber Director, NSA, and CISA, must form an AI cybersecurity clearinghouse, in voluntary collaboration with the AI industry and critical infrastructure operators. The EO tasks the clearinghouse with three concrete functions, per Section 2(d): Coordinate and deconflict scanning for software vulnerabilities Discover and validate those vulnerabilities Coordinate and prioritize the remediation and distribution of vulnerability patches. Grant funding for AI vulnerability detection. OMB, with the National Cyber Director and CISA, must determine whether existing federal grant programs have funding that can be directed toward applicants developing advanced AI vulnerability detection (Section 2(e)). Within 60 days: Cybersecurity workforce. The Office of Personnel Management must expand hiring and placement pathways for cybersecurity specialists through the United States Tech Force (Section 2(f)). Secure frontier model deployment. Treasury, NSA, and CISA, in consultation with NIST and others, must develop a classified benchmarking process to assess the advanced cyber capabilities of AI models. They must also set the threshold for designating a “covered frontier model,” and design a voluntary framework through which developers can give the government up to 30 days of pre-release access to those models. The Executive Order is explicit that it does not create any mandatory licensing, preclearance, or permitting requirement for AI models (Section 3). No fixed deadline: Criminal enforcement. The EO directs the Attorney General to prioritize enforcement against those who use AI to illegally access or damage computer systems (Section 4). For federal cybersecurity leaders, this is less a future-state policy document than a near-term planning trigger. Watch for CISA’s issuance of BODs and other guidance, and for readouts on the clearinghouse, during June and July. How Tenable can help The EO’s center of gravity — finding software vulnerabilities, validating them, prioritizing them, and driving remediation — is the work Tenable's platform is built to do. While the AI Executive Order focuses on vulnerability discovery, validation, prioritization, and remediation, the benefit of the Tenable One Exposure Management Platform is that it addresses vulnerabilities alongside other security weaknesses, including misconfigurations of AI systems and overpermissioned AI agents, to serve as the system of action for mitigating cyber exposure and reducing cyber risk across organizations’ expanding attack surfaces. Below, learn how specific Tenable capabilities map to the EO’s requirements. Continuous vulnerability detection across the attack surface Sections 2(a) through 2(d) turn on the ability to find vulnerabilities across a wide range of systems continuously. Tenable One Vulnerability Management and Tenable Security Center provide network-based and agent-based assessment across IT assets, with credentialed scanning for greater depth. Tenable One Cloud Exposure extends that visibility to cloud workloads and configurations, and Tenable One Attack Surface Management maps internet-facing assets that agencies may not know they have. For agencies operating classified or air-gapped environments — relevant to the National Security Systems named in Section 2(a) — Tenable Enclave Security is built to run vulnerability and configuration assessment inside those boundaries. Risk-based prioritization, not “patch everything” Section 2(d) doesn’t only call for discovering vulnerabilities — it calls for prioritizing them for remediation. That distinction matters because no agency can patch everything at once. Tenable’s Vulnerability Priority Rating (VPR) uses machine learning, trained on the company’s corpus of more than 1.7 trillion security findings accumulated over more than 25 years of continuous scanning, to forecast which vulnerabilities are most likely to be exploited, so defenders can focus on the smaller set that represents real, immediate risk. By leveraging AI-generated features and expert intelligence from Tenable's Research Special Operations team, VPR helps organizations pinpoint the critical 1.6% of vulnerabilities that represent actual business risk . Tenable also ingests CISA’s Known Exploited Vulnerabilities (KEV) catalog — the continuously updated, authoritative list of Common Vulnerabilities and Exposures (CVEs) under active exploitation — directly into prioritization, aligning remediation guidance to the same source CISA uses to track risk across the federal enterprise. AI-enabled defensive tooling Section 2(c) directs CISA to establish or expand programs that enhance AI-enabled defensive tools. As frontier AI models accelerate the rate at which vulnerabilities can be discovered and exploited , the traditional window for manual remediation is rapidly closing. The June 2026 AI Executive Order recognizes this shift, directing federal agencies to counter machine-speed threats with AI-enabled cyber defenses within 30 days. Tenable Hexa AI , the agentic engine of the Tenable One Exposure Management Platform , is designed to help counter machine-speed threats, supercharge productivity, and accelerate risk reduction by automating multi-step remediation workflows. Security teams can leverage pre-built agents directly in the user interface or build custom agents via the Model Context Protocol (MCP), turning exposure intelligence into decisive action at machine speed. At the same time, as agencies build custom models or adopt third-party tools like ChatGPT and Copilot, they fundamentally expand their attack surface. It is now critical to protect enterprise AI, shadow AI, training data, and underlying infrastructure from emerging threats like adversarial attacks, data poisoning, and model theft. Tenable secures this expanding attack surface with Tenable One AI Exposure , which is designed to help agencies see, manage, and control the risks introduced by generative AI. Tenable One AI Exposure allows agencies to discover and inventory AI tools and libraries, and apply AI usage policies across the environment — a growing requirement as agencies adopt AI and need to account for it as part of

By participating in Project Glasswing and working with Claude Mythos Preview, Tenable can help customers better understand how emerging frontier AI models behave, their evolving risks and benefits for cybersecurity, and the kinds of controls organizations will need as AI adoption accelerates. Key takeaways Tenable is also interested in using Mythos Preview to drive new research, strengthen the security of Tenable, and help customers better understand how emerging frontier AI models behave, their evolving risks and benefits, and the kinds of controls organizations will need as they accelerate AI adoption. Tenable previously announced the integration of the Tenable One Exposure Management Platform with the Claude Compliance API to give Tenable customers better AI visibility and governance capabilities, along with Claude-powered workflows in Tenable Hexa AI, the agentic engine of the Tenable One platform. Over the past year, it has become increasingly clear that AI is going to fundamentally reshape cybersecurity. Not eventually. Now. The pace of vulnerability discovery is accelerating. Attack surfaces are expanding faster than ever. Security teams are already overwhelmed trying to determine what actually matters. At the same time, frontier AI models like Claude Mythos Preview are demonstrating that new capabilities in reasoning and agentic workflows are on the horizon and could significantly accelerate cyber offense and challenge cyber defense over the next few years. Tenable joining Project Glasswing is a strategic step forward for defenders, and an extension of our existing partnership with Anthropic . We also believe the industry is entering a period where defender advantage will not come from access to any single model. It will come from understanding what matters most, reducing exposure before attackers strike, and coordinating remediation at the speed modern threats demand. Improving what matters most The industry already has more findings than humans can realistically process. The real challenge is understanding what matters most. Which exposures are actually dangerous? Which combinations create meaningful attack paths? What should be fixed first? What actions will materially reduce risk? Those are exposure management problems. We’re working with frontier AI models to evaluate and benchmark how advanced reasoning capabilities may improve exposure analysis, attack path understanding, prioritization, and remediation decision-making to help our customers and partners improve their own security and risk management initiatives. As part of Project Glasswing, we’re particularly interested in driving new research using Mythos Preview to better understand where it can help reinforce existing security analysis, and strengthen our own defenses by using frontier models to improve the security of Tenable. We also plan to use Mythos alongside other models to help challenge assumptions, and identify relationships and risk patterns faster than traditional approaches alone. We believe frontier models will increasingly become another important source of security insight and telemetry flowing into exposure management platforms. The long-term differentiator for defenders will not be access to a single model. It will be the ability to combine those signals with authoritative context, asset intelligence, attack path analysis, and coordinated remediation across the enterprise. Understanding the AI attack surface Another important reality is that organizations are increasingly responsible for AI systems they did not build themselves. That creates a rapidly expanding attack surface. Our goal is simple: when meaningful advances in AI capabilities arrive, we will be ready to translate them into practical customer value quickly and responsibly. Participating in frontier AI initiatives like Project Glasswing help us better understand emerging model behaviors, evolving risks, and the kinds of controls organizations will need as AI adoption accelerates. That learning directly informs both our products and our own internal security practices. The future of cybersecurity One thing is becoming increasingly clear: frontier AI capabilities will not remain rare for long. Capabilities that seem extraordinary today will eventually become widely available across the industry, including to attackers. In that world, defender advantage will not come from access to any single model. It will come from understanding what matters most, reducing exposure before attackers strike, and coordinating remediation at the speed modern threats demand. That is the work we’re focused on at Tenable. That is our commitment to our partners and customers. And we’re excited to be doing it alongside Anthropic and the broader Project Glasswing community.

This entry discusses research on using large language models (LLMs) to assist in vulnerability discovery. The research involved comparing manual vulnerability discovery in Zenitel's TCIV-3+ video intercom with automated analysis using Anthropic's Claude Opus 4.6. The findings highlight nuanced results about the capabilities and limitations of AI-driven vulnerability research. No specific new vulnerability details, exploits, or affected versions are provided. There is no indication of active exploitation or patches related to this research. The post primarily serves as an exploration of AI's role in vulnerability research rather than reporting a direct security threat.

The PCPJack threat actor compromised approximately 230 cloud servers and repurposed them into a hidden SMTP relay network. The attacker left their deployment toolkit publicly accessible in an unauthenticated open directory, facilitating discovery and analysis. Indicators include a systemd service named xsync disguised as a system sync utility, files under /var/tmp/. xs, and Chisel reverse SOCKS5 tunnels on ports 10000-14999. A public blog post provides detailed MITRE ATT&CK mappings and HuntSQL detection queries. No official patch or remediation guidance is currently available.

A threat actor is using an AI-built ransomware attack toolkit that automates Active Directory discovery and helps evade endpoint detection and response (EDR) solutions. [...]

Improper Input Validation, Improper Control of Generation of Code ('Code Injection') vulnerability in Apache ActiveMQ Broker, Apache ActiveMQ All, Apache ActiveMQ. Non-parenthesized discovery wrappers such as `masterslave:vm://...,...` and `static:vm://...` incorrectly pass validation allowing bypass of fix in CVE-2026-34197. Original description from CVE-2026-34197. Apache ActiveMQ exposes the Jolokia JMX-HTTP bridge at /api/jolokia/ on the web console. The default Jolokia access policy permits exec operations on all ActiveMQ MBeans (org.apache.activemq:*), including BrokerService.addNetworkConnector(String) and BrokerService.addConnector(String). An authenticated attacker can invoke these operations with a crafted discovery UR that triggers the VM transport's brokerConfig parameter to load a remote Spring XML application context using ResourceXmlApplicationContext. 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 issue affects Apache ActiveMQ Broker: before 5.19.7, from 6.0.0 before 6.2.6; Apache ActiveMQ All: before 5.19.7, from 6.0.0 before 6.2.6; Apache ActiveMQ: before 5.19.7, from 6.0.0 before 6.2.6. Users are recommended to upgrade to version 5.19.7 or 6.2.6, which fixes the issue.

Improper Input Validation, Improper Control of Generation of Code ('Code Injection') vulnerability in Apache ActiveMQ Broker, Apache ActiveMQ All, Apache ActiveMQ. Apache ActiveMQ Classic exposes the Jolokia JMX-HTTP bridge at /api/jolokia/ on the web console. The default Jolokia access policy permits exec operations on all ActiveMQ MBeans (org.apache.activemq:*), including BrokerService.addNetworkConnector(String). An authenticated attacker can invoke these operations with a crafted discovery URI that triggers the VM transport's brokerConfig parameter using the "masterslave:// " URL which can allow loading a Spring XML application context using ResourceXmlApplicationContext. 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 issue affects Apache ActiveMQ Broker: before 5.19.7, from 6.0.0 before 6.2.6; Apache ActiveMQ All: before 5.19.7, from 6.0.0 before 6.2.6; Apache ActiveMQ: before 5.19.7, from 6.0.0 before 6.2.6. Users are recommended to upgrade to version 5.19.7 or 6.2.6, which fixes the issue.

This is a public release of an advanced, fully automated Server-Side Request Forgery (SSRF) testing framework designed for security researchers, bug bounty hunters, and penetration testers. The tool automates discovery, validation, and analysis of SSRF vulnerabilities, including cloud metadata testing and advanced testing modules such as WebSocket, gRPC, Kubernetes, and serverless SSRF. It integrates AI-assisted payload generation and analysis to improve testing efficiency. The project is intended strictly for authorized security testing and research. There is no indication of active exploitation or malicious campaigns associated with this tool. No official patches or vendor advisories apply as this is a testing framework, not a vulnerability itself.

mcp-security provides Security and Authorization support for Model Context Protocol in Spring AI. Prior to 0.1.9, the mcp-security framework fails to implement the mandatory SSRF mitigations outlined in the Model Context Protocol (MCP) security specifications. Specifically, it processes untrusted URLs for OAuth-related discovery and metadata without verifying if the targets are malicious or internal to the network. This only affects installations with Dynamic Client Registration (DCR) enabled This vulnerability is fixed in 0.1.9.

My name is Oscar Uribe, Security Researcher at Fluid Attacks. I am reaching out because we have identified a security vulnerability in Pimcore 12.3.3 that we would like to report to you so we can coordinate a responsible disclosure together. As part of our standard disclosure measures, we follow a timeline (outlined at https://fluidattacks.com/advisories/policy), which is aligned with ISO/IEC 29147:2018 and ISO/IEC 30111:2019. In short, the timeline works as follows: we ask for acknowledgment of the report within a few days of your first accessing it, and from there, we are happy to coordinate a joint disclosure date with you, typically within 90 days of the initial discovery. This gives your team reasonable time to assess, develop, and release a fix. We have reserved the CVE ID **"CVE-2026-5394"** for this issue, and the advisory will eventually be published at [https://fluidattacks.com/advisories/dragons](https://fluidattacks.com/advisories/dragons). We are committed to coordinating the timing of that publication with you. Please feel free to reach out if you have any questions about the report, the process, or the timeline. We are glad to work with you on this. ## Description An authenticated administrative user who can import or save DataObject class definitions can inject attacker-controlled composite index metadata and trigger unintended SQL execution in the backend. The vulnerable flow accepts `compositeIndices` from imported JSON, stores the values without strict validation, and later concatenates them directly into `ALTER TABLE ... DROP INDEX` and `ALTER TABLE ... ADD INDEX` statements executed through Doctrine DBAL. Although the original report focused on `compositeIndices.index_key`, independent code review shows that the strongest and most reliable injection point is `compositeIndices.index_columns`, because it is inserted verbatim inside the `ADD INDEX (...)` clause. This permits injection of additional `ALTER TABLE` subclauses against Pimcore object tables without relying on stacked queries. ## Vulnerability ### Root cause 1. Source: - `Pimcore\Model\DataObject\ClassDefinition\Service::importClassDefinitionFromJson()` accepts `compositeIndices` directly from imported JSON. 2. Assignment: - `Pimcore\Model\DataObject\ClassDefinition::setCompositeIndices()` does not enforce an allowlist for index names or column names. - The only special handling is a ManyToOne relation rewrite to `__id` and `__type`, which is not a security control. 3. Sink: - `Pimcore\Model\DataObject\Traits\CompositeIndexTrait::updateCompositeIndices()` builds raw SQL with string concatenation and executes it via `$this->db->executeQuery(...)`. 4. Missing protection: - `quoteIdentifier()` is used for the `SHOW INDEXES` query, but not for the dynamic `ALTER TABLE` statements. - No server-side schema validation restricts `index_key` or `index_columns` to known safe identifier characters. ### Confirmed source-to-sink path 1. `importClassDefinitionFromJson()` decodes attacker-controlled JSON and forwards `compositeIndices`. 2. `setCompositeIndices()` stores those values without sanitizing identifier content. 3. `ClassDefinition::save()` reaches `ClassDefinition\Dao::update()`. 4. `Dao::update()` calls `updateCompositeIndices()` for: - `object_store_<classId>` - `object_query_<classId>` 5. `Localizedfield\Dao` also calls `updateCompositeIndices()` for: - localized query tables - localized store tables ### Why this is exploitable The vulnerable `ADD INDEX` statement is built as: ```php 'ALTER TABLE `'.$table.'` ADD INDEX `' . $key.'` ('.$columnName.');' ``` `$columnName` is produced from `implode(',', $columns)` and is not quoted or validated. A malicious `index_columns` element such as: ```text slider), DROP COLUMN `oo_className` -- ``` produces SQL of the form: ```sql ALTER TABLE `object_query_<id>` ADD INDEX `c_poc_idx` (slider), DROP COLUMN `oo_className` -- ); ``` This remains a single `ALTER TABLE` statement, so the base vulnerability does not depend on multi-statement support. The attacker can inject additional DDL clauses affecting the target Pimcore object table. ### Impact The issue allows a privileged attacker to alter backend SQL behavior during class-definition import/save and modify schema on Pimcore object tables associated with the affected class. Practical impact includes: - unauthorized schema modification on object query/store tables - backend denial of service by breaking expected table layout - data integrity impact for DataObject storage and queries `index_key` is also concatenated into SQL without proper identifier escaping, but the most defensible exploitation path is through `index_columns`. Relevant code: - `models/DataObject/ClassDefinition/Service.php:92-137` - `models/DataObject/ClassDefinition.php:994-1006` - `models/DataObject/Traits/CompositeIndexTrait.php:30-85` - `models/DataObject/ClassDefinition/Dao.php:217-218` - `models/DataObject/Localizedfield/

Learn how attackers exploit automated bot traffic as part of software supply chain attacks to artificially inflate download counters and mask malicious payloads as legitimate. Key takeaways Volume doesn’t equal trust. Packages with numerous versions and high download counts might seem legitimate, but attackers can easily manipulate those metrics. Attackers exploit automated infrastructure. By initially flooding the registry with numerous benign versions of a package, threat actors trigger automatic downloads from mirrors, scanners, and analysis bots, which artificially inflate traffic. Although old download-inflation techniques still work, attackers are developing new sophisticated techniques to deceive developers into installing malicious packages. Downloads count metric Following recent software supply chain attacks in which Tenable has seen attackers steal access tokens and secrets from developer workstations and CI/CD build servers, we started actively monitoring and analyzing npm packages uploaded to the public registry. Initially, we used download counts as a primary metric to determine package relevance. During our monitoring, we identified a recurring anomaly: Brand new packages displayed unusually high download counts within hours of upload. Upon further investigation, we discovered that those packages also had many versions. We found that packages whose content got updated frequently — usually by systematically uploading many new versions for the same package — had an unusually high downloads count. We observed this technique being used deliberately in the wild for the first time in our analysis of the malicious “ambar-src” package , which reached more than 50,000 downloads in three days after attackers uploaded more than 700 versions. We named this technique “download pumping.” Developers and security tools frequently use download counts as one of the metrics to assess a package's legitimacy. Since there is no simple method for determining if a package is legitimate, this artificial inflation effectively disguises the threat. Analysis In the “ambar-src” campaign, threat actors systematically published hundreds of benign versions of the package before introducing the actual malicious payload. Because npm registers each interaction with these updates as traffic, this repetitive version-publishing process achieved two goals: It heavily populated the package’s release history, creating a dense changelog that made the project appear actively maintained and historically legitimate to developers evaluating it. Every time a new version was published, automated systems like repository mirrors and analysis bots automatically downloaded it. Because the attackers systematically uploaded hundreds of versions, they artificially generated a massive wave of automated traffic, inflating the package's download count to more than 50,000 downloads in just three days. From Tenable’s initial analysis, each version uploaded to the npm public registry typically receives between 100 and 150 downloads from automated systems. We verified that fact by running our proof-of-concept (POC) and analyzing the download count. Download pumping PoC To validate these mechanisms, we conducted a POC that replicated the download pumping behavior. We created test packages and systematically published a high volume of new versions to the npm registry. As the npm team stated in their blog , their download stats are naive by design, and they do not put much effort into filtering automated bot traffic. Thus, various repository mirrors, analytical bots, and automated security scanners immediately pulled each new version we uploaded. This validated that an attacker can predictably generate a baseline of downloads entirely through automated publishing, requiring zero organic user interaction. During our POC, we wanted to see how different package properties might affect the automated download volume. We were working under the assumption that packages with postinstall scripts raise the interest level of security scanners. Postinstall scripts are highly interesting to defenders because attackers frequently use these lifecycle hooks to automatically execute malicious payloads the moment a package is installed. Since this is a common malware-deployment technique, automated security scanners prioritize downloading and inspecting packages that have these scripts configured. It is important to note that security scanners don’t have to download the package itself to determine if the npm package has a postinstall script configured, as this data is available in the package metadata in the public registry. For those reasons, we believed that security scanners are more likely to download packages with install scripts configured, as they are more likely to contain malicious code. We deployed three distinct test packages to npm to test our assumption and observed the following results: Version bump only: 135.55 downloads per version This was our baseline test package. We didn’t add or remove any code when publishing a new version, nor did we make any other attempt to make the package look interesting. We simply bumped up the version number each time. Static postinstall script: 141.91 downloads per version This was our second test package, and the first one to have a postinstall script configured, but we didn’t change the script when publishing new versions. Dynamic postinstall script: 158.16 downloads per version In this third test package, we changed the postinstall script every time we bumped up the version. We did this as we believed that security scanners would be more interested in packages whose postinstall script changed, as it could be an indicator of compromise. Graph showing how Tenable’s first POC software package experienced a spike in downloads when we started publishing new versions of it. This data demonstrates a straightforward cause-and-effect: automated infrastructure and security scanners naturally generate more download traffic for packages that exhibit interesting or actively changing behaviors. Other package managers While our research focused specifically on the npm ecosystem, the fundamental mechanics behind this technique are not unique to npm. Other package registries such as PyPI , RubyGems , and NuGet operate with similar automated infrastructure — mirrors, security scanners, and analysis bots — that pull new versions as they are published. Although the specific download amplification and trust metrics may differ across ecosystems, the core principle remains the same: where automated systems react to new publications, there is potential for abuse. Real-world example of download pumping As already stated, we first observed this technique being used in the wild during our analysis of the “ambar-src” package . Let’s look at this in more detail. The attackers created an npm package containing utility code that can be used for legitimate purposes, such as MathUtils, StringUtils and Time functions. The attackers then systematically uploaded 428 legitimate versions of the package in just two hours. The attackers did this to gain initial credibility and attempt to lure developers to use their code. Three days later, the attackers uploaded a new version containing malicious code. By this point, the attackers’ package already had more than 30,000 downloads. In total, the attackers uploaded 724 versions including malicious and legitimate versions. This led to an artificially generated wave of automated traffic, resulting in around 50,000 downloads total. This repetitive version-publishing process successfully inflated the package's download count and created a dense release history, making the project appear historically legitimate before the malware was deployed. Past research on npm download manipulation The manipulation of npm downloads metrics is not a new discovery. In a 2021 research blog , independent developer Andy Richardson showed how prone the npm registry’s download tracking is to abuse, by demonstrating that bad actors can send HTTP requests to a package’s tarball URL to fake downloads. Using automated tools, the researcher successfully drove nearly 1 million spoofed downloads in a single week for a completely unused package. Tenable validated this technique still works in 2026. By sending HTTP requests directly to the URL of the package’s tarball, Tenable successfully inflated a test package’s metric to 17,000 downloads in approximately one hour, using nothing more than a standard office laptop and an internet connection. However, this new version-flooding method we’ve identified offers two distinct advantages: First, it provides amplification, because an attacker gains 100 to 150 automated downloads from repository mirrors for every single version they upload, rather than just one download per HTTP request. Second, systematically publishing these updates populates the release history, creating a dense version log that makes the package appear actively maintained and historically legitimate. Mitigation of supply chain attacks Organizations should not depend on download counts or version histories to determine if a package is legitimate. As we have demonstrated, attackers can easily fake these metrics using automated systems, creating a false sense of trust. Instead, organizations should adopt common industry best practices, such as version pinning and implementing minimum package-age restrictions. These best practices are effective, as security vendors and the open-source community actively monitor these registries and typically detect malicious packages fairly quickly, within a couple of days at most. By enforcing a short waiting period of three to four days before allowing a new package or new version of an existing package into your environment, you allow the community time to identify these threats in the public registry. Once they are detected, they are removed from the public registry, eliminating the risk. It is worth noting that npm is actively working to improve the security of its ecosystem. Recent efforts include adding support for package-age checks directly in the npm CLI, as well as strengthening authentication mechanisms for package maintainers to reduce the risk of account takeovers. While these are meaningful steps in the right direction, the reality is that no single measure can fully prevent malicious code from reaching the public registry. Supply chain attacks will continue to evolve, and organizations should also layer their own defenses rather than rely on the ecosystem alone. For example, organizations can add extra protection for CI/CD build servers by deploying ephemeral CI/CD runners that are destroyed immediately after a single use to prevent malware from lingering. Operating those temporary runners without persistent storage makes it harder for threat actors to save their payloads or establish persistence across different build jobs. Additionally, organizations should enforce least-privilege network access. Restricting outbound traffic makes it harder for malicious payloads running on the build server to reach the open internet to download second-stage malware payloads like “msinit.exe.” So what? Currently, developers are still being hacked through open-source supply chain techniques . The metrics developers and security tools depend on — download counts, version history, maintenance activity — are superficial indicators that, as we have demonstrated, an attacker can manipulat with minimal effort. But the problem runs deeper than fake signals. Even when a package has a legitimate track record with a trusted maintainer behind it, that trust can be compromised overnight. Recent waves of account takeovers, social engineering campaigns, and credential theft targeting established maintainers have shown that a package's history is no guarantee of its current safety, even for legitimate packages. A new version published under a trusted name can carry a malicious payload, and the package manager has no built-in mechanism to catch it. In practice, there is no deterministic method to determine if a new package is malicious or not. Therefore, each package you install and use must be treated like it could be malicious. The meaningful trust signal comes after the fact: from security vendors and the open-source community actively scanning and analyzing packages once they are published. This is exactly why enforcing minimum-age requirements on new packages and new versions is such an effective control . A short waiting period of a few days gives the security community time to detect, flag, and remove threats from the public registry before they ever reach your environment. Organizations that consume packages the moment they are published are accepting risk that is entirely avoidable. Download pumping is ultimately just the initial entry vector for a much larger objective. Attackers using these techniques are generally aiming for one of two outcomes. First, they aim to compromise build servers and CI/CD pipelines. By successfully injecting a malicious dependency into these systems, threat actors achieve “God-mode” over the infrastructure, which can lead to a full compromise of the entire production environment. Second, and even worse, they aim to compromise the developers of highly popular packages. By hijacking a trusted maintainer’s environment, attackers can inject malicious code that thousands of downstream organizations automatically pull, creating a massive cascading effect across the broader software supply chain. How Tenable can help defend against supply chain attacks To defend against supply chain attacks, you need to know exactly what code is running in your environment. The Tenable One Exposure Management Platform and Tenable Nessus can help you build a complete asset inventory of the npm packages used across your organization. Use the following Nessus plugins to build an inventory of the npm modules in your environment: 200172 - Node.js Modules Installed (Windows) 179440 - Node.js Modules Installed (macOS) 178772 - Node.js Modules Installed (Linux) As Tenable continuously analyzes your environment, you get direct visibility into exactly what is installed on your systems. This visibility ensures you can quickly locate and remove compromised packages as soon as a new threat is discovered. Beyond building a complete inventory, organizations also need to actively monitor their environments for live threats. Tenable One Cloud Exposure , a CNAPP, builds on this visibility by continuously monitoring your cloud environment to proactively detect these types of supply chain attacks in real time. Together as part of the Tenable One Exposure Management Platform, these tools proactively detect supply chain attacks across your environments, ensuring your security teams can immediately identify and neutralize malicious activity before attackers can fully compromise your production systems.

Cybersecurity leaders and practitioners brought their burning AI cybersecurity questions to EXPOSURE 2026. They left with clear answers and a blueprint for building an exposure management program. Get a recap and see highlights from the event in words and pictures. Key takeaways As frontier AI models simultaneously accelerate the pace of vulnerability discovery and exploitation and drastically reduce the cost and complexity of launching attacks, cybersecurity faces a critical inflection point where traditional threat models and manual workflows are no longer viable. EXPOSURE 2026 gave attendees a much-needed opportunity to connect with peers, learn how they’re addressing the challenges of AI and building it into their workflows, and develop a game plan, with exposure management at its core, for protecting their organizations from AI-powered adversaries. Tenable Co-CEOs Steve Vintz (right) and Mark Thurmond For the cybersecurity leaders and practitioners who attended EXPOSURE 2026 in Boston this week, the event could not have come at a better time. While momentum for exposure management as a means to proactively reduce cyber risk has been building for more than a year, recent rapid advances in frontier AI models have made it even more critical. EXPOSURE ‘26 attendees arrived at Boston’s historic Park Plaza Hotel on Monday, May 18, 2026, just six weeks after Anthropic unveiled its groundbreaking frontier model, Claude Mythos Preview . They showed up with pressing questions about securing AI, the impact of frontier AI models on cybersecurity, and how exposure management can address all that and more. They left with clear answers, following an intensive day of training and two days of thought-provoking mainstage and breakout sessions featuring Anthropic Field CTO (Cyber) Brett Andrews, CISOs from GEICO, Smithfield Foods, Munich Re, and EōS Fitness, and Tenable experts. EXPOSURE 2026 gave attendees a rare opportunity to catch their breath amid the escalating, machine-speed pace of cybersecurity. It kicked off with an immersive day of training that provided attendees with a blueprint for building a successful exposure management program. And it offered them a chance to compare notes with peers and work collaboratively to develop a game plan for protecting their organizations from AI-powered adversaries with exposure management at its core. Cybersecurity’s quadruple AI challenge Four challenges that AI creates for cybersecurity underpinned every session at EXPOSURE 2026: Frontier AI models like Anthropic’s Claude Opus 4.6 and Mythos make it vastly faster, easier, and more economical for threat actors to discover new vulnerabilities and build exploits for them. AI creates new attack vectors (e.g., prompt injection, jailbreaks, model poisoning, context poisoning in memory, etc.) that traditional cybersecurity controls weren’t designed to address. AI expands every organization’s attack surface, giving threat actors even more entry points to exploit. AI functions as a force-multiplier for threat actors, giving them speed and the advanced, 32-step reasoning capabilities required to autonomously execute an entire network attack chain. Anthropic Field CTO Brett Andrews (left) with Tenable SVP of Product Strategy Eitan Goldstein Anthropic’s Andrews discussed the impact of frontier models on cybersecurity, the threat landscape, and how defenders can leverage AI to their advantage. To illustrate what organizations are up against, several presentations highlighted the sharp contrast between the steady acceleration in vulnerability discovery and exploitation, and the simultaneous deceleration in organizations’ patching and remediation. Tenable CTO Vlad Korsunsky In 2021, for example, the median time to exploit was 84 days, according to Zero Day Clock . Today, it’s 1.6 days. Meanwhile, in 2025, it took organizations an average of 43 days to patch critical CVEs, up 34% from 32 days in 2024, according to data that Tenable Research contributed to the 2026 Verizon Data Breach Investigations Report (DBIR) , which was released on the first day of EXPOSURE 2026. Referencing additional data from the DBIR, Tenable Chief Product Officer Eric Doerr noted that 31% of breaches in 2025 began with an unpatched CVE as the initial access vector. This trend will likely intensify, as frontier AI models accelerate vulnerability discovery, unless security teams adapt. Doerr also spoke to data from Tenable showing that nearly two-thirds of breaches begin with something that isn’t a CVE, such as a misconfiguration, stolen credential, or exposed secret. He used this stat to prove the point that if you’re only concerned about CVEs, you’re leaving two-thirds of your organization’s attack surface exposed. It’s this other attack surface beyond just CVEs that exposure management addresses. Tenable Chief Product Officer Eric Doerr AI-powered exposure management: the blueprint for preemptive defense Presenters used these and other statistics from the DBIR, Tenable’s own telemetry, and other sources to make the case for cybersecurity transformation focused on a preemptive and much more autonomous defense. They showed how explosive, enterprisewide adoption of AI combined with AI-enabled threat actors requires that organizations build these exposure management capabilities into their cybersecurity programs: Unified visibility - Continuous, deterministic asset discovery across the entire hybrid attack surface, capturing every vulnerability, misconfiguration, and excessive permission across on-prem and cloud infrastructure, OT environments, and the rapidly expanding AI attack surface. Contextual, AI-powered insights - Moving past standard CVSS scores to focus on real-world exploitability and business impact, and mapping viable attack paths to understand exactly how an attacker could move laterally toward core assets. Machine-speed action - Shifting from manual workflows to automated, orchestrated fixes. Because human teams cannot triage alerts at machine speed, organizations must deploy agentic AI workflows with appropriate guardrails, including human oversight, to proactively harden posture and isolate active threats. Tenable CSO Robert Huber Tenable CSO Robert Huber shared his experience transforming his vulnerability management program and team into an exposure management program and team, which began two years ago. The impetus was the challenge that Huber and his team faced every quarter when he needed to report on cyber risk to the board of directors: His team had to manually gather, aggregate, harmonize, and analyze data from 50 different security tools that each had their own unique way of reporting on risk. Now, Huber’s team can produce reports in minutes. They’ve also extended their scope of visibility from less than 10,000 assets to more than 100,000 assets and reduced alert to ticket volume by 1,500 to 1, all with the same number of staff. A live AI vs. AI attack simulation created and led by Tenable Researchers Robert McSulla and Ben Smith demonstrated the capabilities of a fully autonomous, agentic defense against a fully autonomous, agentic adversary. McSulla and Smith impressed several key points upon their audience, including: Speed is not the only factor in AI-driven attacks. Yes, AI makes threat actors faster. It also makes them smarter. The demo showed how the adversarial agents reason, make decisions, adapt, and find new, unmapped attack surfaces. Defenders can gain the same advantages as attackers. Defensive agents proactively assess posture, develop and deploy patches for vulnerabilities, and take other hardening actions to reduce risk and mitigate threats. Security leaders and their teams need to get comfortable with autonomous defense. Consider your tolerance for fully autonomous defensive agents: Would you let them shut down a service, configure firewall rules, rotate credentials, or write and deploy patches? That’s what it takes to keep up with agentic attacks that achieve their objectives within three minutes. It’s time to build a governance framework for agentic defense. McSulla and Smith built a governance framework for the defensive agents in their simulation that determines intent, evaluates severity levels, and applies rules, such as when to require a human to make a decision or take an action. Bob McSulla (left) and Ben Smith Custom kicks and other fun Amid the seriousness of cybersecurity, attendees got to pick out custom Converse sneakers featuring Tenable’s iconic new branding. The "Sneaker Bar" at EXPOSURE 2026 EXPOSURE attendees also had the chance to experience the perfect summer evening at Fenway Park, home of the Boston Red Sox. An evening at Fenway Park during EXPOSURE 2026 Tenable announcements at EXPOSURE 2026 EXPOSURE 2026 was punctuated by a host of significant announcements from Tenable, including: The general availability of Tenable Hexa AI , the agentic engine of the Tenable One Exposure Management Platform that gives preemptive security teams capabilities to operate at machine speed. New AI initiatives with Anthropic to increase the agentic capabilities of Tenable One. A strategic integration with the Claude Compliance API designed to help customers improve their visibility into Claude usage across their organizations. The release of the Tenable One Open Connector , which allows customers to bring third-party, custom, and internal data from any source into Tenable One. The launch of the Tenable Open Partner Exchange Network . The Tenable Research team’s prolific contributions to the 2026 Verizon Data Breach Investigations Report .