4276 articles
4276 ARTICLES
Cybersecurity researchers have disclosed details of a previously unreported Internet-of-Things (IoT) botnet framework dubbed TuxBot v3 Evolution that shows signs of being developed with assistance from a large language model (LLM), albeit with not so successful results. “While the AI complied with their request to generate botnet code, it included a safety disclaimer that the developer failed
SonicWall patched two recently exploited zero-day vulnerabilities in its SMA 1000 Series secure remote access appliances which may have been chained for unauthenticated remote code execution. Key takeaways CVE-2026-15409 and CVE-2026-15410 are a pair of exploited vulnerabilities that may have been chained together to allow for code execution on SonicWall SMA1000 series appliances. Zero-day exploitation of these vulnerabilities has been observed and confirmed by SonicWall. Patches and indicators of compromise are available and urgent patching is recommended. Background SonicWall’s Secure Mobile Access (SMA) 1000 Series appliances are enterprise-grade SSL VPN gateways which serve as the front door to organizational networks. The SMA series models sit at the edge of the network, internet-facing by design. Because SMA 1000 appliances aggregate remote access credentials and sit directly on the internet, they represent high-value targets for attackers. A compromise at the appliance level can yield administrator credentials, VPN session tokens, and detailed knowledge of the internal network architecture sitting behind the gateway. On July 14, SonicWall disclosed two vulnerabilities that are being exploited together in the wild: CVE Description CVSSv3 CVE-2026-15409 SonicWall SMA 1000 server-side request forgery (SSRF) vulnerability 10 CVE-2026-15410 SonicWall SMA 1000 remote code execution vulnerability (RCE) 7.2 While the advisory does not specify if they were exploited in tandem, together they form a fully remote, unauthenticated path to arbitrary OS command execution on affected appliances. Analysis CVE-2026-15409 is a SSRF vulnerability affecting the SMA 1000 Workplace interface. This flaw allows a remote, unauthenticated attacker to make network requests to locations of the attacker’s choosing. In practice, SSRF on an internet-facing appliance can serve as a pivot, allowing an attacker to probe internal services, relay authentication material, or reach the AMC in a way that bypasses normal access controls. CVE-2026-15410 is a code injection vulnerability in the Appliance Management Console (AMC). The AMC is the administrative interface used to configure the appliance, manage users, set access policies, and monitor sessions. While this flaw does require the user to be authenticated, the potential chaining of these vulnerabilities makes the exploitation path possible without authentication. These flaws have been exploited in the wild as zero-days. While SonicWall has not provided any details on attribution of which threat actors may be behind the attacks, several SonicWall vulnerabilities have been targeted in the past, including the exploitation of zero-days. Historical exploitation of SonicWall vulnerabilities SonicWall products have been a frequent target for attackers over the years. Specifically, the SMA product line has been targeted in the past by ransomware groups, as well as being featured in the Top Routinely Exploited Vulnerabilities list co-authored by multiple United States and International Agencies. Last year, a surge in ransomware activity was tied to the exploitation of SonicWall Gen 7 Firewalls, prompting warnings from multiple security vendors. Given the historical exploitation of SonicWall devices, we put together the following list of known SMA vulnerabilities that have been exploited in the wild: CVE Description Tenable Blog Links Year CVE-2019-7481 SonicWall SMA100 SQL Injection Vulnerability 1 2019 CVE-2019-7483 SonicWall SMA100 Directory Traversal Vulnerability - 2019 CVE-2021-20016 SonicWall SSLVPN SMA100 SQL Injection Vulnerability 1, 2, 3, 4, 5 2021 CVE-2021-20038 SonicWall SMA100 Stack-based Buffer Overflow Vulnerability 1, 2, 3 2021 CVE-2025-23006 SonicWall SMA 1000 Deserialization of Untrusted Data Vulnerability 1 2025 CVE-2024-40766 SonicWall SonicOS Improper Access Control Vulnerability 1 2025 CVE-2025-40602 SonicWall SMA 1000 Privilege Escalation Vulnerability 1 2025 Both CVE-2026-15409 and CVE-2026-15410 have been added to the Cybersecurity and Infrastructure Security Agency (CISA) Known Exploited Vulnerabilities (KEV) Catalog with a remediation date of Friday, July 17, despite only being added on July 14. Given the urgency surrounding these vulnerabilities and the historical exploitation of these devices, immediate patching is recommended. Proof of concept At the time this blog was published, no proof-of-concept (PoC) code had been published for CVE-2026-15409 or CVE-2026-15410. If and when a public PoC exploit becomes available for these vulnerabilities, we anticipate an increase in exploitation as attackers will attempt to leverage these flaws as part of their attacks. Solution SonicWall has released patches to address this vulnerability in SMA1000 models 6210, 7210 and 8200v as outlined in the table below: Affected Version Fixed Version 12.4.3-03245 12.4.3-03453 and later versions 12.4.3-03387 12.4.3-03453 and later versions 12.4.3-03434 12.4.3-03453 and later versions 12.5.0-02283 12.5.0-02835 and later versions 12.5.0-02624 12.5.0-02835 and later versions 12.5.0-02800 12.5.0-02835 and later versions While the advisory does not provide any workarounds, it does include indicators of compromise (IoCs) for threat hunters to determine if any exploitation has impacted their devices. We recommend reviewing the advisory for the most up to date IoCs. Identifying affected systems A list of Tenable plugins for these vulnerabilities can be found on the individual CVE pages for CVE-2026-15409 and CVE-2026-15410 as they’re released. This link will display all available plugins for these vulnerabilities, including upcoming plugins in our Plugins Pipeline. Tenable Attack Surface Management customers are able to identify these assets using a filtered search for SonicWall devices: Get more information SonicWall Security Advisory SNWLID-2026-0008 Join Tenable’s Research Special Operations (RSO) Team on Tenable Connect for further discussions on the latest cyber threats. Learn more about Tenable One, the Exposure Management Platform for the modern attack surface.
Security teams have never had more visibility, yet rarely have they felt more uncertain. Signal pours in from endpoints, identities, cloud workloads, and a sprawling mix of third-party tools. The post Turning threat intelligence into decisive action with Defender Experts appeared first on Microsoft Security Blog.
A malware framework called OkoBot has been running on Windows machines since April 2025, and one of its modules is built to con hardware wallet owners out of their recovery phrase. On an infected PC, the request comes from inside the wallet’s own desktop software. Sometimes it waits until you plug the device in first. The page is malicious. The app around it is the real one you installed, and
Anthropic’s new AI agent for Slack acts under an admin-configured access bundle rather than each user’s own credentials. Here’s how that model works, what admins should understand and how to securely configure it. Key takeaways Claude Tag, Anthropic’s newly launched AI agent for Slack, acts on connected services using shared credentials an admin configures for a workspace or for a specific private channel, not the credentials of the user tagging it. Claude Tag uses the service-identity pattern, like deploy bots, workflow automations, and incoming webhooks, rather than per-user OAuth delegation. As a result, one admin-configured bundle serves everyone in the channel. Inviting someone to a channel where Claude Tag is present lets them converse with Claude and see its output there. What Claude can access is fixed by the admin-configured bundle, and organizations can require claude.ai login and role-based access control before a user may interact with Claude at all. Channel invitations do not confer new permissions on the invitee. As part of Tenable’s ongoing partnership with Anthropic, Tenable Research worked with their security team through coordinated disclosure. Claude Tag lets Slack channel members direct an agent whose reach is defined by the admin-configured access bundle. (Source: Tenable Research) What is Claude Tag? Claude Tag is a multiplayer AI assistant that lives inside Slack. With Claude Tag, which was released by Anthropic on June 23, 2026, anyone in a channel can tag @Claude to hand off tasks, run autonomous jobs over hours or days, and watch the work unfold in-thread. Claude Tag in a Slack channel, using the attached access bundle to read from a connected GitHub repository. The agent responds to any channel member within the bundle’s scope. Source: Tenable Research. In a traditional 1-on-1 AI interaction, such as a chat UI, a command-line interface (CLI), or a Model Context Protocol (MCP)-connected app, the agent acts as you. Claude Tag keeps that model in direct messages: a DM runs on the sender’s own claude.ai account, using that user’s own connectors. In shared channels, however, Claude Tag is a multiplayer agent: It serves many users at once, and no single user’s credentials define its access. There, the agent is given its own identity, with its own permissions, configured once by an admin, and reused by everyone who tags it. The controls governing that access are: The admin’s bundle configuration determines what the agent can do The channel determines where it participates and what it can see Organization-level Claude Enterprise controls, such as required claude.ai login and role-based access control, govern who can direct it Claude Tag also differs from per-user Slack integrations. Slack’s own GitHub integration, for example, uses each user’s personal GitHub OAuth token. When a user runs /github in a channel, the integration acts as that user, and sees only what that user can see. The same is true for Slack’s Jira and Asana apps. Claude Tag works the other way: One shared credential applies to every user in the channel. For GitHub, that credential is a Claude GitHub App installation token scoped to a repository allowlist the organization owner configures. No individual’s OAuth is used, and actions are attributed to the Claude app. Admins can restrict which repositories each channel can reach by attaching different bundles to different channels. For example, a finance channel can be scoped only to finance repos, while an engineering channel only to its own. For non-GitHub OAuth connectors (e.g., Google Drive), the bundle reuses the OAuth credential of the organization’s admin or owner who connected it. Claude Tag’s access model Claude Tag isn’t just a Slack bot; it’s an autonomous AI agent with its own identity, separate from any human user. When someone in a channel types @Claude, the assistant doesn’t act as that user; it acts as itself, using credentials provisioned by access bundles. The identity model for Claude Tag has three layers: A Claude Tag installation bound to a Slack workspace Access bundles that group connector credentials configured once by an admin, such as a Claude GitHub App installation for repositories, and OAuth-approved credentials for other services) Scopes that define which Slack contexts, such as a workspace or a channel, a bundle is available in. An access bundle configured attached to a single Slack channel. The bundle’s scope is set by the admin, not by the users in the channel. (Source: Tenable Research) The trust boundary that admins can control is the scope. Attaching a bundle to a channel is an admin decision: Members of that channel can then direct Claude within the bundle’s scope. For example, they can scope a GitHub app installation to an allowlist of repositories, while for other OAuth connectors they can scope the credential of the admin who connected them. Claude Enterprise admins can additionally require users to log in to their claude.ai account and restrict usage via role-based access control (RBAC), under which non-qualifying users cannot start Claude sessions and their messages in existing threads are treated as untrusted. There’s no mapping from “the Slack user who typed @Claude” back to “what that user is allowed to access in the connected service.” The model also constrains users: Someone acting through Claude cannot bring their own privileges. Writes happen only where the agent is scoped to write, so they land in admin-chosen, visible locations rather than wherever an individual user’s credentials could reach. Anthropic’s documentation states the model explicitly. The attach-to-scope page warns: “A bundle attached to a public channel grants its access to anyone who joins that channel. In most Slack workspaces, anyone can join a public channel, so the channel’s join policy becomes the effective access control for whatever the bundle grants. Keep elevated credentials in private-channel scopes.” Security implications of multiplayer agents Slack channel configuration is now part of your access-control surface. Traditional application identity and access management (IAM) is per-user: Each person authenticates and is gated against their own identity in each system. An agent like Claude Tag instead has its own identity: the admin-configured bundle defines what the agent can reach, and the channel defines where it participates and who can converse with it. Adding a user to a channel lets them direct Claude within that admin-chosen scope; organizations can require claude.ai login and RBAC before a user may direct Claude at all. You should review bundle scope and channel membership together. Slack admins now make decisions that matter for access control. Attaching an access bundle to a channel determines what Claude can reach there. Review bundle attachments with the same rigor you apply to IAM changes, and use organization-level controls, such as required claude.ai login and RBAC) to bound who can direct Claude. Channel invites then govern who can converse with the agent within that admin-chosen scope. You should scope bundles deliberately and pair them with organization-level controls. Keeping elevated bundles in private channels narrows where the agent participates and who can converse with it. A new channel member can see prior scrollback and converse with Claude there, but what Claude can access stays fixed by the admin-configured bundle. The right practice is minimum-privilege bundles per channel, per task, combined with those organization-level requirements. Anthropic’s planned enhancements Anthropic has said publicly that it plans to strengthen Claude Tag’s security offerings with two additions (see Anthropic’s June 24 post, “Agent identity in Claude Tag: a new access model”): Just-in-time credential grants, where a user approves a single sensitive action in the moment without permanently widening the agent’s scope An identity-aware overlay, adding user-level checks on top of an agent’s scope for organizations with more complex clearance structures These are additive options layered onto the channel-scoped agent model, not a replacement for it: agent identity remains a first-class model, and organizations will be able to combine it with user-level checks, or rely on user identity alone for a given channel where it fits their needs. Coordinated disclosure Tenable Research approached Anthropic’s security team via HackerOne to discuss Claude Tag’s access model and worked through coordinated review. Anthropic engaged promptly, provided a detailed clarification of the product’s access model, and confirmed that the admin-experience feedback we raised has been shared with the relevant product team for consideration in the setup flow and documentation. We appreciate their thorough and professional engagement throughout. Timeline (UTC): 2026-06-30 14:57 – Tenable Research submits an initial report to Anthropic via HackerOne (TRA-699). 2026-06-30 17:14 – Anthropic responds with a detailed clarification of Claude Tag’s access model. 2026-07-01 9:49 – Tenable Research replies with follow-up observations regarding the admin configuration experience. 2026-07-02 13:41 – Anthropic confirms the feedback has been shared with the relevant product team for consideration in the setup flow and documentation. 4 ways to better secure multiplayer agents Multiplayer agents aren’t going away. Here are four actions you can take immediately to reduce the access risks they create: Audit your access bundles. For every Claude Tag bundle in your organization, identify the:connectors it holds credentials for scopes it’s attached to users who can direct Claude in those scopes today, making that set deliberate: manage channel membership, and use organization-level controls (such as required claude.ai login and RBAC) so only intended users can direct Claude. Review channel membership and bundle scope together. For channels whose bundles grant sensitive reach, route invites through an approval flow and audit-log them. Scope bundles minimally and manage channel invite policies. Attach only the connectors and repos/scopes the channel actually needs, and configure channel-level invite restrictions so only named admins can add members. Review the named-admin list on the same cadence you review IAM role assignments. Opt for per-user delegation where the use case allows it. Where a shared agent identity is the right tool, such as for long-running autonomous jobs or team-owned automation, scope it minimally and manage its channels’ membership as the IAM boundary it is by default (see #2 and #3), and layer on the organization-level controls, such as required claude.ai login and RBAC where available. Anthropic has said an identity-aware overlay is planned as an additional layer on top of agent scopes.
Threat Advisor could help teams with AI-specific risks. But a broader AppSec strategy rethink is needed in the AI era.
Part 3: How the Red Agent bypassed a credit and paywall system by changing a single client-side value from false to true.
Mozilla has released updates to address two critical flaws in Firefox for which it warned that exploit code has been published. The vulnerabilities are listed below - CVE-2026-15718, an invalid pointer in the JavaScript: WebAssembly component CVE-2026-15719, a site isolation in the DOM: Navigation component “We are aware that exploit code for this is public, however we are not aware of
When you incorporate data from application security scanners into your exposure management platform, you can assess the threat from formerly isolated code flaws using a broader risk context, which illuminates hidden exposures that your security and development teams can eliminate together. Key takeaways Break application security silos and obtain full code-to-runtime visibility by integrating standalone code scanner data with your exposure management platform. By contextualizing application security findings, filtering out alert noise, and automating patches, exposure management helps organizations pinpoint and fix the riskiest coding flaws to your organization. Leveraging exposure management, CISOs can transform technical application-security metrics into clear insights on business resilience that the board and the C-suite can understand, as well as enforce risk-based SLAs, and benchmark against industry peers. Securing the code that enterprise developers write, assemble, and deploy has been a perennial challenge for security teams. As a result, code containing vulnerabilities, misconfigurations, and other security weaknesses routinely gets released into many enterprises’ production systems and customer-facing applications. This happens because application security data often lives in silos within code-scanning tools, which makes it difficult to correlate with the rest of the organization’s security issues in cloud workloads, on-prem assets, operational technology (OT) systems, identity platforms, and more. When application security data exists in a vacuum, the findings can’t be properly and promptly assessed and prioritized. As a result, security teams can’t deliver patches and pull requests with the speed at which developers ship code. This disconnect is only getting wider, as developers use AI tools to further automate and accelerate the creation and release of code into their continuous integration / continuous deployment (CI/CD) software development pipelines. The following stats illustrate how AI coding tools are making application security considerably harder for cyber teams: Developers who use AI coding assistants commit code at three to four times the rate of their peers but introduce security findings at 10 times the rate. 45% of AI-generated code contains known security flaws, such as those listed in the OWASP Top 10 ranking of web application security risks. CVEs directly attributable to AI coding tools tripled month-over-month in early 2026, with March’s total alone exceeding the number of CVEs discovered in all of 2025, according to research from Georgia Tech. So, how can security teams successfully secure their application development lifecycle? Is the term “application security” destined to become an oxymoron in the age of AI? Not by a long shot. In this blog, we explain how the key to securing your entire code-to-runtime lifecycle lies in incorporating the data from your application security tools (ASTs) into your exposure management platform. By doing so, security teams gain full visibility into their application development pipeline and are able to see where it fits into their overall attack surface. They’re also able to assess code risks within a broader context that factors in isolated code issues and security issues present in the rest of the environment, such as cloud workloads, runtime systems, and identities. Leveraging this unified view of the attack surface, security teams can detect toxic combinations of risk that create organizational exposure. This in turn empowers security teams to precisely and quickly prioritize what they need to fix right away, and drastically reduce the number of vulnerabilities in production code. Here are the top 5 reasons you should integrate your application security program with your exposure management platform. 1. Visibility Picture this: A new zero-day vulnerability impacts a popular open-source library — think of the Log4Shell bug that unleashed a crisis for the millions of organizations with the ubiquitous Log4j Java-based logging utility in their environments. Your CISO calls for an all-hands on deck response, starting with an immediate, detailed assessment of all the assets that contain the vulnerable software. This sounds like a daunting, if not outright impossible task, but it’s entirely feasible to fulfill if you have an exposure management platform with a continuously updated, unified inventory of all your software libraries, code repositories, code owners, and associated security issues in a single view. With this comprehensive inventory of your application security data, you can pinpoint where developers write and deploy code, who owns it, where the code is running, and its blast radius. When you make application security part of your exposure management program, you get comprehensive and up-to-date visibility to quickly detect which assets are affected by a headline-grabbing zero-day vulnerability. 2. Agentic AST integration New agentic ASTs, such as Anthropic’s Claude Security and OpenAI’s GPT-5.5-Cyber, will dramatically accelerate discovery of new code vulnerabilities, which will logically increase the number of security issues that potentially need to be remediated. The result is an already massive backlog of application security findings will become even more unmanageable, worsening the security team’s alert fatigue. Here again, an exposure management platform that’s natively integrated with agentic ASTs puts these AI tools’ scanning data in the broader context of your entire attack surface. When you don’t address application security in isolation, you can more quickly, precisely and easily deduplicate code-security findings, investigate issues, analyze and assess risk, and orchestrate remediations and patches. In short, the integration of agentic ASTs with an exposure management platform streamlines the prioritization of application security risks, and automates and accelerates their remediation. 3. Prioritization context Static application security testing (SAST) and software composition analysis (SCA) tools can identify hundreds or thousands of high-risk code vulnerabilities, but these tools often list them with bare-bones data that gives security teams minimal context about their risk to the organization. Which vulnerable code is running in production? Which code lies in decommissioned microservices? Which code sits on an attack path leading to critical systems? Without these insights, you can’t decide which code security issues to fix first. With an exposure management platform, you can assess the criticality of code vulnerabilities and misconfigurations within comprehensive context and prioritize remediation accordingly, taking into account elements such as: Running assets in production vs. in development or test environments User identities and entitlements to understand authority and management privileges External asset accessibility to understand potential new entry points and attack pathways Business criticality about the codebase, application importance, and related compliance requirements. That way, you can determine the different risk levels of the same unauthenticated remote-code execution flaw. For example, the risk is different if the impacted code sits in a QA environment that is completely isolated from the internet, versus if the impacted code resides in your customer authentication application programming interface (API). Assessing code-security risk in this precise, granular manner makes all the difference in the often fraught relationship between developers and security pros. Instead of showing up with a laundry list of hundreds of code issues to fix, the security team can pinpoint a handful instead, explain to developers why those are truly critical, articulate their severity and business impact, and even provide pre-written pull requests to fix them. 4. Organizational exposure CISOs need to understand how code vulnerabilities contribute to the organization’s overall risk posture, so that they can then hold business lines accountable to risk-based service-level agreements (SLAs) and key performance indicator (KPI) metrics. Once application security data gets integrated into the exposure management program, CISOs can: Measure total exposure and risk contribution of code vulnerabilities Define and enforce exposure KPI targets Benchmark risk metrics against external peers Create customized exposure views based on internal reporting requirements Enable unified reporting of all exposures, including static code risks, in a single platform Integrating application security data into an exposure management platform elevates code flaws from a discreet developer issue to a board-level risk metric. The integration empowers CISOs to elevate their board presentations and C-level conversations from, say, SQL injections, to organizational resilience, financial risk, industry benchmarking, operational exposure, and business-line accountability. With these insights, the CISO can: Inform a line-of-business VP about the security and compliance posture of their team’s flagship mobile application Brief the CFO on potential compliance penalties stemming from specific unpatched vulnerabilities Show the CTO which development teams produce the safest code and consistently meet security SLAs 5. Mobilize remediation Application development teams get routinely bombarded with requests to patch and update their code to remediate vulnerabilities and other security issues. Without a single source of truth, developers can’t properly prioritize remediation workflows and security teams can’t easily track the status of bug fixes. With exposure management, security teams can effectively orchestrate and automate a unified remediation process across all assets and their exposures, coordinating remediation tasks that support multiple asset owners, functions, and business units. Exposure management helps consolidate actions and streamline workflows, so that development teams don’t get bombarded with remediation tickets from multiple disconnected tools This remediation orchestration ensures consistent and precise prioritization of remediations, verification of fixes, and report generation via a single exposure management platform. How Tenable can help The Tenable One Exposure Management Platform can ingest, analyze, and normalize static-code security data from ASTs, allowing you to manage application security risk from a centralized platform, along with the rest of your exposure data. Tenable One can ingest data from Snyk (Snyk Code, Snyk Open Source, Snyk Container, and Snyk Infrastructure as Code) via our native Tenable One Connector, and from your other ASTs via the Tenable One Open Connector. This also includes the ability to integrate Claude Security findings as well. This new data source for Tenable One gives you complete, code-to-runtime visibility across your entire attack surface by integrating AST data into your overall exposure management program, where you can correlate it with security data from cloud workloads, OT environments, runtime systems, and more. You can analyze static code risks from code repositories and containers, ingest associated tags, identify owners, determine asset criticality, and calculate asset exposure. If your ASTs function in silos, application security becomes a blind spot, and you lack the context to properly assess the real-world risk of a code vulnerability to your organization. With Tenable One, you can pinpoint the code vulnerabilities with the most critical exposure scores and prioritize their remediation accordingly. Finally, Tenable One helps you measure, track, and communicate total exposure of code vulnerabilities in Exposure View. You can see how your source code impacts your organizational risk posture, define exposure targets, view performance over time, enforce remediation SLAs, and communicate status to executive teams. See how AST findings are integrated into Tenable One Learn more about Tenable One, the exposure management platform for the modern attack surface.
CISA has added two new vulnerabilities to its Known Exploited Vulnerabilities (KEV) Catalog, based on evidence of active exploitation. CVE-2023-4346 KNX Association KNX Protocol Connection Authorization Option 1 Overly Restrictive Account Lockout Mechanism Vulnerability CVE-2026-46817 Oracle E-Business Suite Improper Privilege Management Vulnerability These types of vulnerabilities are frequent attack vectors for malicious cyber actors and pose significant risks to the federal enterprise. Binding Operational Directive (BOD) 26-04: Prioritizing Security Updates Based on Risk establishes vulnerability management requirements for Federal Civilian Executive Branch (FCEB) agencies. BOD 26-04 reinforces the importance of the KEV Catalog and requires federal agencies to prioritize rapid remediation of high-risk vulnerabilities, specifically those identified by Common Vulnerabilities and Exposures (CVEs) listed in CISA’s KEV Catalog on publicly exposed assets that grant total control of the asset post-exploitation, while deferring action for lower-risk vulnerabilities. BOD 26-04 further establishes basic expectations for when agencies must check whether threat actors compromised the system before the patch was applied. While BOD 26-04 applies only to FCEB agencies, CISA encourages all organizations to adopt risk-based vulnerability management and prioritize remediation of KEV Catalog vulnerabilities. CISA will continue to add vulnerabilities to the catalog that meet the specified criteria. Aware of an exploited vulnerability not currently listed in the KEV Catalog? Submit it for potential addition through CISA’s KEV Nomination Form. Potential KEV additions must have a CVE ID, evidence of exploitation, and clear mitigation guidance.
Developed by CISA, the National Security Agency (NSA) and international partners, this joint guidance contains best practices for software manufacturers and online service providers to design and implement a coordinated vulnerability disclosure (CVD) program for working with external security researchers that includes a clear vulnerability disclosure policy (VDP) and process for triaging, remediating and assigning Common Vulnerabilities and Exposures (CVE) identifiers to reported vulnerabilities. The guidance also provides considerations for leveraging third-party intermediaries, like CISA or other national computer security incident response teams, to substitute or supplement a CVD program. By implementing a robust CVD program aligned with this guidance, organizations can work transparently and collaboratively with security researchers to remediate vulnerabilities, build constructive relationships, enhance product security while improving vulnerability management processes, and demonstrate their dedication to protecting customers.
For years, routing traffic through cloud proxies was good enough. Then work moved to the browser, AI entered the workflow, and the inspection model stopped keeping up. Enterprise workflows now live across SaaS applications, browsers, and an expanding ecosystem of generative AI tools, unsanctioned browser extensions, and autonomous agents. Employees routinely paste intellectual property into