Threats tagged 'rce'

A malicious Chrome extension impersonating the Perplexity AI answer engine was found on the Chrome Web Store. This fake extension intercepts users' search traffic and collects browsing information without authorization. There is no indication of known exploits in the wild or an official patch. The threat primarily involves privacy invasion through data interception by a deceptive browser extension.

Decades-old Bash shell tricks can bypass safeguards in most open source AI coding agents, potentially turning malicious repositories into supply chain attack vectors. The post Decades-Old Bash Tricks Expose AI Coding Agents to Supply Chain Attacks appeared first on SecurityWeek .

CISA’s BOD 26-04 changes how federal agencies patch and how security leaders must measure, justify, and communicate cyber risk to executives and boards. Key takeaways BOD 26-04 requires agencies to make and defend risk-based vulnerability prioritization decisions, including decisions to defer vulnerability remediation. This accountability requirement transforms vulnerability management from a technical operation into a governance discipline that demands audit-ready documentation. Traditional vulnerability management KPIs (total vulnerabilities patched, mean time to patch, percentage of systems scanned) do not measure what BOD 26-04 demands. The metrics that matter are coverage breadth and risk-tier remediation rates. Tenable’s analysis of customer telemetry shows that monitoring coverage breadth is a stronger predictor of risk posture than patch speed, a finding independently corroborated by research showing organizations can remediate only about 10% of open vulnerabilities per month regardless of size or maturity. The directive’s reach extends beyond federal agencies to thousands of federal contractors who must align with BOD 26-04 through contract compliance requirements. Organizations in the federal supply chain should treat the directive as an operational requirement, not advisory guidance. The shift from patching metrics to risk exposure metrics is not a federal-only phenomenon. Industry reporting standards, insurance underwriting models, and board-level accountability expectations are converging on the same demand: prove that you are reducing actual risk, not just closing tickets. The reporting mandate hiding inside CISA Binding Operational Directive (BOD) 26-04 Most coverage of CISA BOD 26-04 has focused on the operational requirements: the four-variable model, the 16-tier remediation matrix, the three-day BOD 26-04 patching timeline with mandatory forensic triage. These are significant, and Tenable has covered them in depth in our FAQ on BOD 26-04 . But buried in the directive’s requirements is a less-discussed obligation that may prove equally transformative: agencies must demonstrate how they prioritize vulnerabilities and justify their decisions, particularly in cases where they decide to defer remediation. Metrics are expected to evolve from simple counts of patched vulnerabilities to measures that reflect reduction in high-risk exposure. This is not a minor procedural update. It is a fundamental shift in how cybersecurity programs are measured, reported, and held accountable. For CISOs and security leaders, BOD 26-04 doesn’t just change the patching workflow. While the BOD 26-04 directive formally targets federal agencies, its framework is rapidly becoming the blueprint for the private sector as market forces align around risk-based accountability. Ultimately, it changes what corporate boards of directors need to hear. Why traditional vulnerability management metrics fail under BOD 26-04 For years, security leaders have measured vulnerability management programs by volume: Total vulnerabilities identified Total patches applied Percentage of systems scanned within a 30-day window Mean time to remediate. These metrics are easy to collect, easy to report, and easy to trend over time, but they are also increasingly disconnected from actual risk. Tenable’s own analysis of customer telemetry across our global customer base confirms what many security leaders suspect but cannot prove: breadth of monitoring coverage is a more robust, predictive risk signal than patch velocity. Unmonitored assets exist as a permanently open attack surface; they cannot generate findings, be prioritized, or be verified as remediated. Conversely, monitored assets still pass through the risk pipeline even if remediation isn’t operating at maximum speed. Independent industry research heavily corroborates the need to shift reporting from patching speed to monitoring coverage: The remediation ceiling - The Cyentia Institute’s Prioritization to Prediction research (analyzing 3.6 billion vulnerability observations) found that the typical organization can only remediate roughly 10% of open vulnerabilities per month, regardless of size, industry, or maturity. Because you cannot out-patch the growth rate of your backlog, prioritization, not speed, is the only lever that meaningfully reduces risk. The MTTR flaw - Standard mean-time-to-remediate (MTTR) calculations exclude open, unremediated vulnerabilities, which skews your metrics toward items that are easier to close quickly, which may not be the most critical, severe, or highest-risk issues. Asset composition skew - Remediation half-lives vary wildly across asset types, averaging 36 days for Microsoft Windows systems versus 369 days for network appliances. A strong MTTR often just means you have good visibility into automatically patching Windows assets, but this KPI may hide persistent exposure on edge devices and OT systems. BOD 26-04 makes this explicit: remediation priority is determined by the risk posed by a vulnerability if exploited, not by the total number of vulnerabilities identified. The directive’s deferral tier (fix on system upgrade) formalizes what the data has always shown: most vulnerabilities can wait. The ones that cannot are defined by exploitation evidence, exposure, automation potential, and impact severity. A CISO who reports, “We patched 95% of critical CVEs this quarter,” is reporting a metric that BOD 26-04 has rendered insufficient. The relevant question is: Of the vulnerabilities that posed real-world risk to mission-critical systems, what percentage did we remediate within the directive’s timeline, and how much of our attack surface was under observation when we made that assessment? The new security metrics: What BOD 26-04 demands The shift from volume-based to risk-based reporting requires new KPIs. Organizations implementing BOD 26-04 should consider metrics that reflect the directive’s four-variable prioritization model: Remediation compliance by BOD tier. What percentage of vulnerabilities in each BOD tier (three-day forensic triage, three-day, 14-day, 60-day, system upgrade) are remediated within the applicable timeline? This is the core compliance metric. It replaces “mean time to remediate” with a risk-weighted measurement that distinguishes between a 3-day critical and a deferrable low-risk finding. Coverage of actively exploited vulnerabilities. What percentage of KEV -listed vulnerabilities in the environment are remediated? This measures the response to the most dangerous known threats, not the total vulnerability population. Exposure surface reduction over time. What is the trend in assets classified as publicly exposed (BOD Variable 1)? Reducing the number of internet-facing assets directly shifts vulnerabilities from compressed timelines to the deferral tier. Tenable’s analysis of the full CISA Vulnrichment corpus found that removing an asset from public exposure can shift 76.7% of its associated CVEs to longer remediation windows. This makes exposure reduction the single highest-leverage compliance investment. Additional independent research reinforces why assessment coverage is a better indicator of risk outcomes than patch velocity. Joint analysis from XM Cyber and the Cyentia Institute, examining more than 60 million exposures across 10 million entities, found that 75% of security exposures do not put critical assets at risk: they are dead ends in the attack graph. Only 2% of exposures sit on “choke points,” the convergence nodes through which multiple attack paths transit en route to critical assets. This corroborates Tenable’s telemetry finding from a different angle: if your monitoring does not cover the entities where those choke points exist, your remediation speed on the other 98% is noise in the risk signal. The metric that matters is not how fast you patch, but whether your visibility extends to the places where attack paths converge. Forensic triage completion rate. For vulnerabilities in the highest-risk tier (KEV + total control), what percentage received the required BOD 26-04 forensic triage guidelines within the three-day window? This measures compliance with the directive’s most novel and operationally demanding requirement. Deferral justification documentation rate. For vulnerabilities placed in the “fix on system upgrade” tier, what percentage have documented risk acceptance decisions? BOD 26-04 requires agencies to justify deferral decisions, which means every deferred vulnerability needs an auditable rationale. Mean time from KEV addition to remediation. How quickly does the organization respond when a CVE is added to the KEV catalog and its BOD timeline compresses? This measures the speed of the organization’s response to dynamic timeline changes. These metrics share a common characteristic: they measure risk reduction outcomes, not activity volume. A security program that patches fewer total vulnerabilities but remediates 100% of the 3-day tier within three days is performing better under BOD 26-04 than one that patches twice as many total CVEs but misses the critical timelines. The accountability requirement: Justifying decisions to defer vulnerability remediation BOD 26-04 introduces something federal vulnerability management has never had: a formal requirement to justify prioritization decisions. When an agency defers remediating a vulnerability to the next system upgrade cycle, that decision must be documented and defensible. This creates an audit trail requirement. For every deferred vulnerability, the organization needs to demonstrate: Which of the four variables were assessed What combination placed the vulnerability in the deferral tier Why the agency is confident the deferral does not create unacceptable risk If any of the four variables change (a CVE added to the KEV, an asset newly exposed to the internet), the deferral decision must be reassessed. For CISOs, this means the vulnerability management pro

Chris Thompson's journey took him from hacking game controls as a teenager to founding IBM’s X-Force Red team. The post Hacker Conversations: Chris Thompson, Former Head of IBM X-Force Red, Co-Founder of RemoteThreat appeared first on SecurityWeek .

This is an open-source decision-support tool designed to assist human analysts in triaging Windows malware samples. It integrates multiple analysis techniques including static feature extraction (EMBER2024), SHAP explanations for model interpretability, reverse engineering tools, threat intelligence lookups, and optional sandbox execution to generate draft reports. The tool is an early prototype focused on improving the practical usefulness of model explanations by mapping features to concrete artifacts and indicating confidence levels. It is not itself malware or a vulnerability but a research project to aid malware analysis.

Roughly two dozen companies have notified their customers of the Klue-Salesforce incident impact. The post More Klue Breach Victims Identified as Hackers Get Hacked appeared first on SecurityWeek .

It will provide the tools and channels to report, patch, and disclose open source software vulnerabilities. The post Linux Foundation Unveils New Open Source Security Project Akrites appeared first on SecurityWeek .

In this week’s newsletter, Martin considers how AI will help threat intelligence by creating an easily queryable data source of intelligence reports.

Exclusion Auditor is an open-source, read-only tool designed to identify risky Next-Generation Antivirus (NGAV) exclusions, with an initial focus on CrowdStrike Falcon but vendor-agnostic in design. It audits endpoint security exclusions that may create blind spots or security risks, scoring them based on a set of rules mapped to MITRE ATT&CK techniques. The tool operates read-only, requires minimal permissions, and supports importing exclusions from multiple vendors. It helps security teams identify and remediate potentially dangerous exclusions that could impair defenses. The project is in early development (v0.1) and actively seeks feedback and contributions to improve rule accuracy and reduce false positives.

The latest version of the open source data transfer tool resolves 18 medium and low-severity vulnerabilities. The post 25-Year-Old Vulnerability Patched in Curl appeared first on SecurityWeek .

From hidden content injections to cognitive state poisoning, attackers are turning trusted data sources into traps for autonomous AI. The post When Information Becomes the Attack Surface – Understanding AI Agent Traps appeared first on SecurityWeek .

Hundreds of C&C servers were disrupted in an operation involving law enforcement and several cybersecurity companies. The post Microsoft and Allies Smash Shared Infrastructure of Amadey and StealC Malware appeared first on SecurityWeek .

The security defects allow unauthenticated users to take control of the open source software supply chain. The post Exploitable CI/CD Vulnerabilities Expose Millions of Repositories to Hijacking appeared first on SecurityWeek .

Over a dozen Klue customers have confirmed that hackers stole data from their Salesforce instances. The post BeyondTrust, LastPass Impacted by Klue-Salesforce Incident appeared first on SecurityWeek .

This vulnerability allows remote attackers to execute arbitrary code on affected installations of Unraid. Authentication is required to exploit this vulnerability. The ZDI has assigned a CVSS rating of 8.8. The following CVEs are assigned: CVE-2026-9772.

This vulnerability allows remote attackers to execute arbitrary code on affected installations of Unraid. Authentication is required to exploit this vulnerability. The ZDI has assigned a CVSS rating of 8.8. The following CVEs are assigned: CVE-2026-9773.

LastPass announced that hackers accessed customer data from its Salesforce environment after stealing the company's OAuth tokens in the Klue supply chain attack earlier this month. [...]

A stolen session cookie sat in underground markets for seven weeks before attackers used it to poison 32 Red Hat packages in the npm software registry, an example of the industrial approach behind modern supply chain attacks. Key takeaways Miasma is a self-propagating npm worm derived from Mini Shai-Hulud that TeamPCP open-sourced on May 12. The public release of the full weaponized toolchain means any operator can now replicate structurally identical supply chain campaigns. The Miasma campaign compromised 89-plus npm packages across three waves (June 1-5), affecting Red Hat, Vapi.ai, and Microsoft Azure repositories. The worm produced malicious packages with valid SLSA Build Level 3 provenance attestations, defeating the highest tier of supply-chain integrity verification. The root cause was a stolen developer credential that sat in infostealer logs for seven weeks before weaponization. This infostealer-to-supply-chain pipeline is the defining pattern of the Developer Credential Economy. The Miasma campaign’s third wave (June 5) introduced a significant escalation: persistence files that target AI coding assistants (Claude Code, Cursor, Gemini CLI, VS Code), expanding the attack surface from package registries to the developer’s local environment. Relying on execution-layer detection, such as EDR, is insufficient against supply chain threats because EDR tools lack visibility into the ephemeral CI/CD environments where credential theft and weaponization occur. Organizations should treat developer credentials as control-plane infrastructure and adopt a phased Continuous Threat Exposure Management (CTEM) approach: harden the generation layer, neutralize harvested secrets in real time, and enforce human-gated publishing controls. Background on the Miasma worm and npm supply chain attack On June 1, the Miasma self-propagating worm compromised 32 official npm packages under the @redhat-cloud-services namespace, delivering a credential-harvesting payload to an estimated 80,000 to 117,000 weekly downloads. Within five days, the campaign escalated through three distinct attack waves and forced GitHub to disable 73 repositories across four Microsoft organizations . The technical details of the Miasma supply-chain attack are alarming: valid Supply Chain Levels for Software Artifacts (SLSA) provenance attestations on malicious packages; a novel execution technique that bypasses install-script monitoring; and a new persistence mechanism that targets AI coding assistants. But the most important detail is a timestamp. Dark web monitoring firm Whiteintel detected a Red Hat employee’s GitHub credential and session cookie in infostealer logs on April 13. A second sighting appeared on May 15. The credential sat in underground markets for approximately seven weeks before attackers weaponized it on June 1. That seven-week gap is the signature of an emerging threat model that Tenable’s Research Special Operations (RSO) team calls the Developer Credential Economy , and has been tracking since March 2026. The Developer Credential Economy is a structured black market for highly privileged developer credentials where open-source supply chain compromises function as credential generation infrastructure, underground markets serve as the distribution layer, and multiple threat actors with distinct motivations weaponize the harvested access downstream. The Miasma campaign is the clearest example of this model to date, and it validates a pattern that has been accelerating across the npm, PyPI, and GitHub ecosystems throughout 2026. The three-layer economy, explained through Miasma When it first assessed this pattern in March, Tenable RSO built the analysis around the TeamPCP cascading campaign (Trivy, KICS, LiteLLM, Telnyx, and 66+ npm packages) and the Sapphire Sleet/UNC1069 Axios compromise . The thesis identified a three-layer structure: credential generation, distribution, and weaponization. Three months later, the Miasma campaign validates each layer with striking clarity. Layer Actor / group Operational focus Primary targets Miasma validation Generation TeamPCP Bulk credential harvesting via tool exploitation Trivy, KICS, TanStack, Red Hat npm scope Miasma's payload sweeps GitHub tokens, cloud credentials, CI/CD secrets, SSH keys, and .env files from every infected environment Distribution Underground markets, infostealer aggregators Credential brokering and tooling proliferation Stolen developer credentials; open-sourced worm code Red Hat employee credential sat in infostealer logs for seven weeks before weaponization; Shai-Hulud source published May 12 Weaponization Sapphire Sleet (DPRK-nexus), LAPSUS$, Miasma operator, copycat actors State-sponsored exfiltration, data theft, cascading supply chain compromise Axios (npm), Mercor AI, @vapi-ai/server-sdk, Azure/durabletask Each Miasma wave generates A fresh credential pool, feeding the next wave and enabling downstream actors Layer 1: Credential generation The Developer Credential Economy’s first layer is extraction. Threat actors compromise developer tooling and open-source infrastructure not primarily to distribute malware to end users, but to harvest the credentials those environments contain, such as GitHub tokens, npm publishing tokens, cloud provider credentials, CI/CD secrets, SSH keys, and API keys. TeamPCP pioneered this at scale beginning in September 2025 with the original Shai-Hulud worm. Its defining innovation was cascading credential extraction: compromise one trusted tool, harvest the credentials it holds, and use those credentials to compromise the next tool in the dependency chain. The Trivy vulnerability scanner compromise yielded CI/CD runner secrets. Those secrets enabled the KICS compromise . KICS yielded additional cloud credentials. Each link in the chain generated a broader set of privileged access. By May, TeamPCP had refined this into the Mini Shai-Hulud variant, which introduced two capabilities that made the generation layer dramatically more efficient: Wormable propagation : The malware queries the npm registry for every package the compromised identity can publish, and republishes itself across all of them automatically. CI/CD pipeline hijack via OpenID Connect (OIDC) token extraction : Rather than stealing static credentials, Mini Shai-Hulud requests short-lived OIDC tokens through GitHub Actions, enabling it to publish packages with valid cryptographic provenance. In the Miasma supply chain campaign, this generation layer operated through a Red Hat employee’s compromised GitHub account. The worm’s payload swept the infected environment for: GitHub tokens and personal access tokens npm publishing tokens AWS, GCP, and Azure cloud credentials HashiCorp Vault tokens Kubernetes service account tokens SSH private keys Docker registry credentials GPG keys .env files The June variant added dedicated collectors for GCP and Azure cloud identities, going beyond secret extraction to enumerate all cloud access the infected machine holds. Every machine that ran npm install against a compromised @redhat-cloud-services package version became a credential generation node. Layer 2: Distribution The second layer is the marketplace. Stolen credentials flow from the generation layer into underground markets, infostealer log aggregators, and access brokering services, where they become available to any buyer. The Miasma supply chain-attack timeline makes this layer visible in a way previous campaigns did not. Whiteintel detected the Red Hat employee’s GitHub credential and session cookie in infostealer logs on April 13. That credential was not generated by a targeted supply chain attack against Red Hat; a commodity infostealer harvested it, one of 13.2 million infostealer infections that SpyCloud's 2025 Identity Exposure Report documented as producing an average of 50 credentials per infection. The credential entered the distribution layer as one data point among billions: SpyCloud recaptured 5.3 billion credential pairs, 18.1 million exposed API keys and tokens, and 8.6 billion stolen session cookies from criminal underground monitoring in 2025 alone. For seven weeks, the credential sat in the distribution layer before someone acted on it. That dwell time is the systemic gap that the Developer Credential Economy exploits. Organizations that do not monitor underground markets for exposed developer credentials are operating on the assumption that the generation-to-weaponization pipeline does not exist, or that it operates too slowly to matter. Miasma demonstrates that even a seven-week window, which is long by underground market standards, is more than sufficient for weaponization. The distribution layer was further amplified on May 12, when TeamPCP published the complete Mini Shai-Hulud source code on GitHub under an MIT License with the message “Shai-Hulud: Open Sourcing The Carnage.” The release included CI cache-poisoning scripts, the OIDC token extractor, and the credential stealer with its propagation logic. This is the supply chain equivalent of publishing a working exploit framework: the tooling itself became a distribution channel, lowering the barrier to entry for any operator who wants to run a structurally identical campaign. Layer 3: Weaponization The third layer is operational use. Actors with distinct motivations acquire credentials from the distribution layer and weaponize them against specific targets. In March, the RSO team documented at least three distinct actors operating from the same credential pool : TeamPCP harvested at scale: Sapphire Sleet/UNC1069 (DPRK-nexus) operationalized stolen npm tokens for financial gain through the Axios compromise and LAPSUS$ exploited compromised Tailscale VPN credentials from the LiteLLM breach for data theft from Mercor AI. The same credential ecosystem fed all three. Miasma’s weaponization layer continues to evolve, but the trajectory across its three waves demonstrates the pattern: Wave 1 (June 1) used the stolen R

Attackers can send crafted media files to execute code in any application that uses FFmpeg’s libavcodec library. The post FFmpeg PixelSmash Flaw Allows RCE on Video Players, Media Servers, NAS Appliances appeared first on SecurityWeek .

The Volume Booster Chrome extension, with approximately 2 million weekly users, silently activated a commerce-tracking SDK (Give Freely) between versions 1.0.2 and 1.0.4 without triggering Chrome's permission re-consent prompt. The extension had previously been granted broad host permissions that were dormant until the SDK was activated. This SDK collects device identifiers, geolocation data, and telemetry continuously, regardless of user interaction with the extension's visible UI. The Chrome Web Store listing's privacy declaration does not disclose these data flows, creating a discrepancy between declared and actual behavior.