Wiz Research uncovered the Gheist campaign, a Gheist GitHub campaign planting 13,500 rogue branches across 850+ accounts to steal private repo secrets.

Related Posts:

• Exposed Cairn AI Panels Reveal Autonomous Hacking Against Over 1,100 Targets
• GMO Desktop Cloud Breach Exposes 26,000 FX Servers
• Suspected Chinese Operator Uses ARTEX AI Framework in Global Hacking Campaign

The post Gheist Campaign Abuses Stolen GitHub Tokens Across 850 Accounts to Steal Secrets appeared first on Daily CyberSecurity.

GitHub now expires npm trusted publishing setups that miss a first publish within 48 hours, closing a repo name reuse flaw in 1,500+ packages.

Related Posts:

• Google Updates Chrome VRP Rewards for Memory Flaws
• Google Play AI Apps Revolutionize Android Publishing
• Google Gemini 4 Argon Model Officially Launches

The post npm Trusted Publishing Now Expires After 48 Hours appeared first on Daily CyberSecurity.

A CVSS 10 GeoServer Cloud vulnerability in a GitHub Actions workflow could have leaked repository secrets. No abuse found, and the workflow is gone.

Related Posts:

• Critical Apache PLC4X Flaw Lets Attackers Hijack OPC UA Connections to PLCs
• TeamViewer Fixes Five High-Severity Flaws in Full Client and Host
• Electron Fixes Five High-Severity Sandbox and Isolation Vulnerabilities

The post GeoServer Cloud Fixes CVSS 10 GitHub Actions Flaw That Exposed Repository Secrets appeared first on Daily CyberSecurity.

GitGuardian discovered 474 leaked GitHub App private keys still active. Learn how exposed GitHub App private keys threaten organizations like the CDC.

Related Posts:

• Meta Muse Secretly Used Humans for AI Phone Calls
• ShinyHunters Syndicate Alleges Major FBI Network Compromise
• OpenAI's Project Lily Employs Humans to Read ChatGPT Chats

The post Leaked GitHub App Private Keys Expose Critical Infrastructure appeared first on Daily CyberSecurity.

1. Executive summary

Modern software is assembled, not written. A single application routinely draws on hundreds of third-party components, pulled in on demand and updated continuously as part of normal process. That convenience has quietly become a dependable initial-access route that bypasses traditional perimeter and endpoint defenses. Rather than breaching a hardened production perimeter, adversaries increasingly compromise the developer, the maintainer account, the build pipeline, or the package registry — and let trusted automation carry their code the rest of the way.

A $1.8 million App Store scam lawsuit tests how much software vetting Australian firms can safely outsource.

The post Why Apple’s Recent Crypto Lawsuit Should Worry Australian IT Leaders appeared first on TechRepublic.

Healthcare software vendor Craneware confirmed attackers stole data during a cyberattack, underscoring growing cybersecurity risks facing healthcare suppliers.

The post Craneware Confirms Data Theft After Cyberattack, Investigations Underway appeared first on TechRepublic.

At GitHub Security Lab, we spend a lot of our week talking to maintainers. Some find the settings page dense and the docs sprawl. Most maintainers we talk to weren’t hired to be security engineers. While this is true, ignoring a project’s security settings completely will lead into leaving a lot in the table in terms of automation and scalability, leading into a poor security posture, and before you realize it to vulnerabilities that pile up, exposing your users.

Here’s the short version. Six settings, free to use, updated in less than half an hour. We’ve bundled them into a guided flow called Protect Your Project so you can do them in one pass, and we walk through each tool you’ll use below.

1. Add a SECURITY.md file

This is the lightest-lift setting on the list and the one that makes everything else easier.

A SECURITY.md file tells the people who find bugs in your project where to send them. Without one, your options for a well-meaning reporter are a public issue (now a public exploit) or your personal email (if they can find it).

You don’t need to write much. We suggest adding a communication means such as an email so that those reporting vulnerabilities can reach you directly without posting about them publicly. Then, you can state what bugs are in scope, alongside anything else a reporter should have in mind when contacting you. For reference, we point maintainers to the the systemd project’s security policy that we consider a complete example. It sets clear expectations about reproducers and doesn’t assume you have a 24/7 response team when you don’t. Borrow the structure, change the contact details, commit it.

Ten minutes, tops.

2. Turn on private vulnerability reporting

SECURITY.md tells reporters where to go. Private vulnerability reporting (PVR) gives them a private place to make their report.

Once enabled, a researcher can file a confidential advisory on your repo. You triage it out of the public eye and disclose on your timeline. The setup is one checkbox in Settings → Security.

If you only do one thing tonight, do these first two together. They are free, and are the fastest signal to your community that you take this seriously.

3. Turn on secret scanning, with push protection

This is the one with the most embarrassing failure mode.

GitGuardian’s State of Secrets Sprawl 2026 found 28.65 million new secrets leaked on public GitHub in 2025, a 34% jump over the prior year and the largest single-year increase on record. AI-assisted commits are leaking secrets at roughly twice the baseline rate. The average cost of a data breach now sits at $4.44 million globally ($10.22 million in the US) per IBM’s 2025 Cost of a Data Breach Report.

Secret scanning catches keys and tokens that slip into your repo by blocking them locally before they’re pushed to your repository. It doesn’t matter if your repo is public or private, because once secrets leave your local development, then they are available to anyone with access to your repo.

4. Turn on Dependabot and dependency review

Your project isn’t just your code. It’s the dozens (often hundreds) of packages your code pulls in.

Looking at WordPress, for example: this search for reviewed, critical-severity advisories mentioning WordPress returns a long list of plugins with known vulnerabilities. If you’re running a WordPress site, Dependabot helps ensure none of these plugins are sitting in your dependencies.

Dependabot alerts you when a package you depend on has a known vulnerability. Dependency review shows you, inside a pull request, exactly what’s being added or upgraded and whether any of it has an open advisory. Together they turn an opaque package.json diff into a two-minute review.

5. Turn on code scanning

Code scanning runs static analysis on your repo and flags the patterns that lead to real bugs. SQL injection. Command injection. Dangerous deserialization. The usual cast.

Code scanning with CodeQL can detect unsafe GitHub Actions workflows. CodeQL is the engine, and we built code scanning. We made it free for open source in 2019, and it now ships as a one-click default setup in your Security and Quality tab.

This is the setting most maintainers skip because it sounds like it needs configuration. It doesn’t. Default setup picks the right query pack for your language and runs on every pull request.

6. Turn on branch protection on your default branch

This is the simplest, least-flashy setting, but it will yield the biggest impact starting as soon as you turn it on. This is about requiring a pull request before merging to main with minimum one approval.

This catches the worst-case scenario: a compromised credential, a confused contributor, or a tired version of you pushing straight to production. It’s also what makes the other five settings actually bite, because now Dependabot alerts and code scanning findings block a merge instead of sitting in a tab you never open.

In conclusion

These six settings will not make your project unhackable. Nothing will.

What they will do is close the easy doors, the ones being walked through right now by people scripting through public repos at scale.

Turn these on, and your project will be meaningfully harder to attack than it was this morning. So will every project that depends on it.

The post 6 security settings every GitHub maintainer should enable this week appeared first on The GitHub Blog.

In May 2026, the GitHub Advisory Database published 1,560 reviewed advisories—more than five times our typical monthly output and the highest in its history.

And it still wasn’t enough to keep up.

Over the past few months, the vulnerability ecosystem has shifted in a fundamental way. Input across private vulnerability reports, repository advisories, and CVE requests has increased simultaneously, pushing the entire system to a new operating scale.

This blog builds on an ongoing GitHub community discussion tracking the evolving nature of vulnerability reporting, as well as PVR and Advisory Database roadmap developments. A recurring theme in that thread is the downstream impact of platform changes on advisory curation and data quality. This aligns with GitHub’s broader shift toward emphasizing quality and shared responsibility in vulnerability reporting, which in turn directly shapes how advisory data must be curated and maintained.

TL;DR

Review times for new advisories are longer because vulnerability volume and complexity have increased significantly. Advisory quality has not changed: reviewed advisories are still human-validated, and existing alerts continue to function normally. If you want to help, focus on three things: submit complete vulnerability data, coordinate closely with maintainers and researchers, and request CVEs only when there is a clear intention to publish.

Record output and unprecedented input

May was not a one-time spike. From March through May, we sustained more than 6,000 advisory decisions per month. This included updating existing advisories, publishing new advisories, and reviewing inbound advisories, and exceeded any prior three-month peak.

At the same time, inflow accelerated across every source:

• Private vulnerability reports across the platform increased from ~550/week in January to more than 3,000/week for most of May.
• Repository advisories scaled from ~650/week to more than 5,000/week.
• GitHub CNA CVE requests reached almost 4,000 in May alone, nearly 10x year –over year.
• The CVE program has already published 30,000+ CVEs in 2026.
• More than 1.7 million total repositories have enabled private vulnerability reporting.

This is not a localized surge. It reflects structural change across the vulnerability disclosure ecosystem.

The impact

Since mid-April, due to this surge, we have not consistently met our internal goals for publication. Processing times extended first to about a week, then to multiple weeks for a meaningful share. Longer publication times can increase exposure windows. We take that seriously, and timeliness is a core part of the value this database provides.

What’s still working

Our data pipelines and publishing infrastructure have continued to operate through this period. Imports are running, data integrity is intact, and published advisories are accurate. Advisories that reach reviewed status today meet the same quality standard as before.

CVE assignment quality has remained strong. Our assignment rate has held between 91–94% through the entire surge, consistent with or better than historical norms and showing that there hasn’t been a clear degradation in the requests we receive.

The issue is throughput. The system that validates, enriches, and publishes advisory data is functioning; it is now operating beyond the volume and complexity it was designed to handle.

The work isn’t uniform

Not every security advisory requires the same level of effort. Some arrive well formatted: the advisory details clearly name the affected package and its relevant ecosystem, the version range is documented, and the fix is tagged. A curator can validate and publish these in under a few minutes.

But a growing share of incoming advisories require more investigation:

• Package disambiguation. The advisory details say “foo”, but is that foo on npm, python-foo on PyPI, or the unrelated foo on Maven? When upstream data doesn’t specify an ecosystem, our curators figure it out.
• Version range reconstruction. Many security advisories arrive with no affected version range, or with ranges that don’t match actual release history. Curators trace commits, changelogs, and tags to determine what’s actually affected.
• Multi-ecosystem advisories. Some projects ship packages to multiple registries, like a library with both a .NET implementation (NuGet) and a JavaScript implementation (npm) of the same functionality, where a vulnerability in the shared logic affects both. This requires independent verification across multiple data sources.
• Conflicting upstream data. When the CVE record, the maintainer’s advisory, and the commit history disagree about what’s affected, someone has to determine the truth.

Historically more straightforward advisories dominated, and the harder ones could be absorbed. When volume surges, the queue fills with both, and the complex ones take disproportionately longer, creating a compounding effect. The mix now matters much more. This isn’t just more work; it’s significantly more complex.

What “reviewed” actually means

A reviewed advisory is not simply a republished record; it’s the result of verification.

Curators:

• Map vulnerabilities to the correct ecosystem package
• Validate affected and fixed versions against release history
• Confirm upstream accuracy
• Check for duplication and consistency
• Validate classification and scoring

This is what allows downstream tools to rely on the data without additional validation.

Publishing faster by skipping verification would increase false positives at scale, which can create more risk than delay.

A broader ecosystem shift

This trend extends beyond GitHub.

The volume of reported and published vulnerabilities continues to grow rapidly, and organizations across the ecosystem are adapting to that change.

The system is working as designed. More vulnerabilities are being reported, disclosed, and tracked than ever before. That creates pressure downstream, including during advisory curation.

What we’re doing now

• Improving community contribution quality and throughput. Community contributions are an important part of how we improve the Advisory Database, and each is reviewed against the same validation standard as any other advisory. We’ve strengthened triage and prioritization, so high-quality submissions are identified earlier, reviewed more consistently, and moved through the queue faster. This helps us respond to current volume while reinforcing our primary goal of maintaining a high-quality, trusted dataset.
• Scaling the systems behind curation. We’ve increased aspects of the capacity of our backend curation systems to handle higher sustained throughput and we’re continuing to modernize the data infrastructure that supports analytics and queue management.
• Building AI-assisted research tools. We’ve developed and deployed tooling that gives our curators AI-powered assistance during the research phase of advisory review. Curators still make every decision, but routine research can be completed faster for higher quality advisories.
• Expanding automation where it helps the most. We’ve improved automation for extracting more data from upstream CVE information and for handling how community contributions interact with already-reviewed advisories. That work reduces time per decision without lowering the quality bar.
• Investing in documentation and training. We’ve significantly expanded our operational documentation. This enables us to bring new team members up to speed faster and improves consistency across the team.

What we’re building next

To support this new scale, we are investing in:

• Reducing time-per-advisory for the most common cases. A significant portion of incoming advisories require research that follows predictable patterns, such as identifying the correct package, confirming the version range, and checking for a fix. We’re investing in tooling that accelerates these patterns, so curators can spend their time on genuinely ambiguous cases that require human judgment.
• Making risk-based review prioritization smarter. We’re exploring additional risk signals for prioritization, such as package usage, evidence of active exploitation, and ecosystem impact to ensure the advisories that matter most reach users first.
• Improving the feedback loop with upstream data sources. A significant share of curation time is spent correcting incomplete or inaccurate upstream data. We’re investing in tighter integration with the sources we ingest from, especially through increased repository GitHub Security Advisory and Private Vulnerability Reporting data validation, so that data quality issues get resolved closer to the origin rather than in our review queue.
• Continuing to be transparent. We’ll share updates on our progress as we make it. If things improve, we’ll tell you. If we hit new challenges, we’ll share that too.

What this means for you

• Dependabot users: Existing alerts are unaffected. New advisories may take longer to trigger, with critical issues prioritized.
• API and feed consumers: Reviewed data remains accurate; unreviewed advisories are visible but not yet validated.
• Maintainers: Repository advisories continue to flow into the global database; prioritization is based on several factors, including project impact and severity.

How you can help

Include complete data in vulnerability reports. Providing affected version ranges, root cause, and clear reproduction steps makes a direct difference in how quickly and accurately advisories can be reviewed. When this data is complete, curation can take minutes. When it isn’t, curators must reconstruct missing details from source code, release history, and conflicting upstream signals. At this scale, those gaps compound quickly. High-quality upstream data is one of the most effective ways to improve both speed and accuracy across the ecosystem.

Include the right advisory details. Our best practices guide covers ecosystem categorization, package names, and version range formatting, but a few additional details make a direct difference in how quickly and accurately advisories can be reviewed and published to the GitHub Advisory Database. 

• Use the package name as it appears in the registry. Advisory package names must match the registry, not the repository or project name. Downstream systems rely on registry identifiers to match advisories to affected dependencies. If the name is incorrect or missing, alerts cannot be reliably generated, and affected users may never be notified. Using the registry name ensures the advisory can be correctly linked, indexed, and distributed.
• List all affected packages. Some vulnerabilities impact multiple packages within a project. Each affected package should be listed separately with its own ecosystem, package name, and version range. Advisories are consumed at the package level, so missing a package means missing the users who depend on it. Including all known affected packages improves coverage and ensures alerts reach the full set of impacted users.
• Provide a complete CVSS vector string. The GitHub Advisory Database supports CVSS 3.1 and 4.0. A severity label such as “High” is a quick summary, but a complete CVSS vector string includes a richer set of attributes, such as attack complexity, required privileges, and user interaction, which describe the vulnerability in greater detail. This structured information allows severity to be validated, interpreted consistently, and used by downstream tools for prioritization and automation. Without it, scoring is less precise and harder to compare across advisories. If you include a score, use the official calculators and include the full vector.
• Include relevant CWE classification. A CWE identifies the underlying weakness behind a vulnerability, such as cross-site scripting, SQL injection, or deserialization of untrusted data. Unlike a narrative description, a CWE gives downstream tools and security teams a standardized way to understand what kind of issue they are dealing with. That matters because CWE data can be used to categorize, filter, prioritize, and compare vulnerabilities across large datasets. It helps organizations group related issues, apply policy or reporting rules, and understand patterns in the vulnerabilities affecting their software. The more specific the CWE, the more useful the advisory becomes for downstream consumers.

For more guidance, see the best practices for writing clear, complete security advisories.

Be intentional when requesting CVEs. Requesting a CVE ID signals that a vulnerability will be disclosed and tracked publicly. When requests are made without plans to publish, it can divert time and attention from advisories that are actively moving toward release. Aligning CVE requests with clear publication intent helps ensure that effort is focused on where it has the most immediate impact and keeps the system responsive for everyone.

Coordinate closely with maintainers and other researchers. High-quality advisory data depends on shared context. Aligning affected packages, version ranges, and fixes helps reduce ambiguity and conflicting information across sources. At this scale, small gaps in coordination can become large inconsistencies downstream.

Improve advisory quality by contributing pull requests to the Advisory Database. Every correction to version ranges, package mappings, or fixes improves the accuracy that developers rely on.

Recognize the scale of this ecosystem shift and take part in it. The increase in vulnerability reporting reflects real progress. More issues are being found, fixed, and disclosed than ever before. Maintaining quality at this scale depends on researchers, maintainers, and data consumers and producers working together toward the same goal.

The bigger picture

Two years ago, the database published ~270 advisories per month.

In May 2026, it published over 1,500 while processing thousands of additional decisions across the system.

This reflects a broader shift:

• More repositories are enabling responsible disclosure.
• More researchers are reporting vulnerabilities.
• More maintainers are publishing fixes and advisories.
• The vulnerability ecosystem is scaling toward greater transparency.

That growth creates pressure on systems like ours. But it also represents meaningful progress.

Every advisory improves visibility. Every alert reduces risk.

We are scaling to meet that reality, and we will continue to share progress as we do.

The post Inside the Advisory Database and what happens when vulnerability volume breaks records appeared first on The GitHub Blog.

Tata Electronics is investigating a cyber incident after leaked files reportedly included manufacturing documents for Apple and Tesla.

The post Tata Electronics Leak Exposes 200,000 Files, Including Apple and Tesla Documents appeared first on TechRepublic.

AI supply chain security: Explore the risks of poisoned datasets, compromised open-source libraries, and AI-powered phishing.

The post Securing the AI Supply Chain: What are the Risks and Where to Start?   appeared first on Security Boulevard.

Over the past year, a new pattern has emerged in attacks on the open source supply chain. Attackers are focusing on exfiltrating secrets (like API keys) in order to both publish malicious packages from an attacker-controlled machine as well as gain access to more projects in order to propagate the attack.

These attacks often start by compromising a workflow on GitHub Actions.

Let’s talk through what you can do today to secure your GitHub Actions workflows, what work GitHub has been doing to secure open source, and what to expect in the coming months for further security enhancements.

What you can do today

Many of these attacks start by looking for exploitable GitHub Actions workflows.

The most critical action you can take is to enable CodeQL to review your GitHub Actions workflow implementation (available for free on public repositories) to inspect your workflows for security best practices.

Next, review our detailed actions security guidance. In particular:

• Don’t trigger workflows on pull_request_target.
• Pin third-party Actions to full-length commit SHAs.
  • This pinning should be done by you or Dependabot; be suspicious of external pull requests that update this content.
• Look out for script injection when referencing user-submitted content.

When an attack happens, we publish information about compromised dependencies in our Advisory Database. You can get up-to-date information directly from the Advisory Database or use tools like Dependabot (also free for public repositories) to notify you when you have malicious or vulnerable dependencies.

What we’ve done

These attacks follow the same pattern: they focus on exfiltrating secrets to publish malicious packages from an attacker-controlled machine, as well as using those malicious packages to gain access to more projects to propagate the attack.

Instead of using secrets in your workflows, you can use an OpenID Connect token that contains the workload identity of the workflow to authorize activities. We’ve worked with many systems to integrate with Actions this way, including cloud providers, package repositories, and other hosted services.

Specifically, GitHub partners with the OpenSSF to support this security capability, called trusted publishing, in package repositories, which is now supported across npm, PyPI, NuGet, RubyGems, Crates, and other package repositories. Not only does trusted publishing remove secrets from build pipelines, it also provides a valuable signal when a newly published package stops using trusted publishing: the community uses this signal to investigate if the package came from an attacker using exfiltrated credentials.

npm is the largest package repository in the world, with over 30,000 packages published each day. We scan every npm package version for malware, and our detections are constantly updated and improved as attacks evolve. Hundreds of newly published packages contain malicious code daily, so when detected, a human reviews to confirm it’s a true positive before we take action. At this scale, even a 1% false-positive rate would disrupt hundreds of legitimate publishes daily.

What to expect in the coming months

In late 2025 the Shai-Hulud attacks motivated a revamped security roadmap for npm, which we talked about in Our plan for a more secure npm supply chain and Strengthening supply chain security: Preparing for the next malware campaign. In response to Shai-Hulud we accelerated the roll-out of capabilities like npm trusted publishing, continued work on malware detection and removal, and engaged with open source maintainers on what npm security capabilities would have the biggest positive impact. Even when the community agrees a change must be made, those changes can mean that people need to change their workflow, or worse, cause backwards incompatibility. We’re working to provide as smooth a transition as possible.

Similarly, with the most recent round of attacks we are revisiting our security roadmap for GitHub Actions and accelerating actions security capabilities where work was already underway. You can give us feedback on the GitHub Actions security roadmap in the community discussion post.

Where do we go from here?

Open source is a global public good and one of humanity’s greatest collaborative projects. We have not seen the end of attacks on open source, but GitHub is committed to defending it across npm, actions, or whatever comes next. As we work on rolling out these security capabilities, we look forward to your feedback on what’s most impactful and how we manage the transition to a more secure future.

The post Securing the open source supply chain across GitHub appeared first on The GitHub Blog.

See how the attack works, what to look for, and how to remediate.

The post Poisoned Axios: npm Account Takeover, 50 Million Downloads, and a RAT That Vanishes After Install appeared first on Security Boulevard.

GitHub published 4,101 reviewed advisories in 2025. This is the fewest number of reviewed advisories since 2021.  Does this mean open source is shipping more secure code? Let’s dig into the data to find out.

GitHub reviewed advisories

Fewer advisories reviewed doesn’t mean fewer vulnerabilities were reported. The drop is because GitHub reviewed far fewer older vulnerabilities. When you look only at newly reported vulnerabilities from our sources, GitHub actually reviewed 19% more advisories year over year.

So why the change? Quite frankly, we are running out of unreviewed vulnerabilities that are older than the Advisory Database. At the same time, the number of newly reported vulnerabilities hasn’t dropped.

It’s also worth clarifying that “unreviewed” in the database can be misleading: most advisories marked unreviewed have already been looked at by a curator and found not to affect any package in a supported ecosystem, so they may never be fully reviewed.

This means that you should be receiving fewer brand-new Dependabot alerts about old vulnerabilities. 

Note: If you find an unreviewed advisory that affects a supported package, please let us know so we can get it reviewed!

How vulnerabilities were distributed across ecosystems in 2025

The distribution of ecosystems in advisories reviewed in 2025 is similar to the overall distribution in the database, with the exception of Go. Go is overrepresented in 2025 advisories by 6%. This is largely due to dedicated campaigns to re-examine potentially missing advisories found through an internal review for packages where we had inconsistent coverage.

How the types of vulnerabilities changed in 2025

* An advisory may have more than CWE. For example, an advisory might have both CWE-400 and CWE-770. It would then count for both.

As usual, cross-site scripting (CWE-79) is by far the most common vulnerability type. However, there are significant changes in the following areas. Resource exhaustion (CWE-400 and CWE-770), unsafe deserialization (CWE-502), and server-side request forgery (CWE-918) were unusually common in 2025. CWE-863 (“Incorrect Authorization”) saw a significant jump, but that is largely due to reclassification away from CWE-284 (“Improper Access Control”) and CWE-285 (“Improper Authorization”), which are higher level CWEs that the CWE program discourages using.

One of the biggest quality improvements in 2025 was more specific, more consistent CWE tagging. Advisories without any CWE dropped 85% (from 452 in 2024 to 65 in 2025). CWE-20 (“Improper Input Validation”) is still common, but in prior years it was often the only CWE listed on an advisory. 

In 2025, advisories far more often list CWE-20 plus one or more additional CWEs that describe the concrete failure mode. This added specificity makes the data more actionable for triage, prioritization, and remediation.

To find out how to filter Dependabot alerts by CWE, see our documentation on auto-triage rules.

How to prioritize your response

We provide two scoring systems for prioritization: 

• Common Vulnerability Severity Score (CVSS): Scores how severe the impact of the vulnerability will be
• Exploit Prediction Scoring System (EPSS): Provides a measure of how likely the vulnerability will be attacked in the next 30 days and 

Together, they can give you a head start on your risk assessment process.

As you can see, when considering impact, most vulnerabilities skew moderate to high of the impact range. Low-impact vulnerabilities are likely more common than the CVSS data suggests but are often not considered worth the time and effort for researchers and maintainers to report. The EPSS scores for moderate to high impact vulnerabilities support this decision.

So should you trust the EPSS or CVSS scores? To judge that, let’s look at how they match up to vulnerabilities in CISA’s Known Exploited Vulnerabilities Catalog. The exploited vulnerabilities are at least scored moderate, and most are critical or high. While CVSS has more of the exploited vulnerabilities as critical, it also has far more vulnerabilities in the range in general. Combining the two can help you prioritize which vulnerabilities to address to prevent exploitation.

npm malware advisories

2025 was a huge year for npm malware advisories. Due to large malware campaigns, such as SHA1-Hulud, GitHub saw a 69% increase in published malware advisories compared to 2024. This is the most malware advisories GitHub has published since our initial release of historical malware when we added support in 2022.

You can receive Dependabot alerts when your repositories depend on npm packages with known malicious versions. When you enable malware alerting, Dependabot matches your npm dependencies against malware advisories in the GitHub Advisory Database.

GitHub CVE Numbering Authority (CNA)

CVE publications

2025 was a big year for the GitHub, Inc. CNA. We saw a 35% increase in published CVE records, outpacing the overall CVE Project’s increase of 21%.

In fact, we saw 10 to 16% growth every quarter. If this trend continues, GitHub will publish over 50% more CVEs in 2026.

You can help make that a reality by requesting a CVE from us the next time you publish a repository security advisory about a vulnerability!

Organizations using GitHub’s CNA

Every year, GitHub sees more organizations use its CNA services. 2025 is no exception with a 20% increase in new organizations requesting CVE IDs.

Unlike reviewed global advisories, which are always mapped to packages in ecosystems we support, any maintainer on GitHub can request a CVE, even if they don’t publish that package to a supported ecosystem. In fact, 2025 is the first year that GitHub has published more CVEs from organizations that do not use a supported ecosystem than those that do.

We would like to thank all 987 organizations that published CVEs with us in 2025 and highlight the top 10 most prolific organizations.

* Organizations that published CVEs through GitHub for the first time in 2025

Onward to 2026

The data from 2025 shows incredible growth: 

• 4,101 reviewed advisories 
• 7,197 malware advisories 
• 2,903 CVEs published
• 679 new organizations using our CNA services. 

These numbers represent real security improvements for millions of developers.

You can be part of this in 2026. Here’s how: 

1. Use our CNA services

Publishing CVEs shouldn’t be complicated. Request a CVE directly from your repository security advisory, and we’ll take care of curating and publishing it for you. It’s free, it’s fast, and it helps the entire ecosystem understand and respond to vulnerabilities.

2. Improve advisory accuracy

Found an unreviewed advisory affecting a supported package? See incorrect severity scores or missing affected versions? Suggest edits. Your edits will be reviewed by the Advisory Database team and ultimately, will help make the database more accurate for everyone. In 2025, 675 contributions from the community improved the quality of this data for the entire software industry!

3. Protect your projects

The most direct impact you can have is protecting your own code. Enable Dependabot to automatically receive security updates and explore GitHub Advanced Security for comprehensive protection.

4. Make reporting a vulnerability easier

Let researchers know how to report to you and what you will and will not accept by creating a security policy for your repository. Enable private vulnerability reporting to make the coordination process smooth and secure.

Let’s make 2026 even better. See you in next year’s review! 🚀

The post A year of open source vulnerability trends: CVEs, advisories, and malware appeared first on The GitHub Blog.

Software supply chain attacks are evolving. Beyond compromised packages, discover the 2026 "Agentic" threat surface—where prompt injection, toolchain poisoning, and hallucinated dependencies bypass traditional DevSecOps. Learn how the 3 Pillars and AI-driven sandboxing provide a new defensive architecture.

The post Coding Agents Widen Your Supply Chain Attack Surface  appeared first on Security Boulevard.

On March 20, 2026 at 20:45 UTC, Aikido Security detected an unusual pattern across the npm registry: dozens of packages from multiple organizations were receiving unauthorized patch updates, all containing the same hidden malicious code. What they had caught was CanisterWorm, a self-spreading npm worm deployed by the threat actor group TeamPCP. We track this […]

The post CanisterWorm: The Self-Spreading npm Attack That Uses a Decentralized Server to Stay Alive appeared first on Security Boulevard.

Open source has always been about community.

It’s about maintainers who review pull requests late at night. Volunteers who respond to security reports from strangers. And communities that quietly power the world’s software.

The reality behind the commits is that maintainers get stretched thin. The effort of responding to pull requests and comments, while also being expected to merge and ship, adds up quickly. Late nights turn into burnout, one-person projects become critical infrastructure overnight without even realizing it, and “thank you” doesn’t pay the bills. Plus, AI is an accelerating force that’s changing how the open source community secures the ecosystem. The requirements of always-on security take more time and energy in addition to not always having the knowledge and expertise.

At GitHub, we believe supporting open source means more than hosting code. It means investing in the people who maintain it, giving them the tools they need to succeed, and standing with them as the ecosystem evolves rapidly in the AI era. Open source maintainers deserve better support and security, and we’re listening and investing.

Strengthening open source security, together

Today, we are joining Anthropic, Amazon Web Services (AWS), Google, and OpenAI with a combined commitment of $12.5 million to support the Linux Foundation’s Alpha-Omega initiative to advance open source security. This collaboration is aimed at helping maintainers make emerging AI security capabilities accessible and integrated into existing project workflows, and at further advancing our OSS security programs, to strengthen the security of critical open source software projects.

This effort builds on years of GitHub’s work as a steward of open source and software security. Real impact comes from pairing investment with practical tools, education, and long-term support designed to help maintainers.

Today, over 280,000 maintainers on GitHub across hundreds of millions of public repositories are eligible for free access to core GitHub platform services, GitHub Copilot Pro, GitHub Actions, and security capabilities, like code scanning and Autofix, secret scanning, push protection, and dependency alerts. Our GitHub Security Lab works with the open source community to educate and protect at scale against the most common threats, and it publishes security advisories that help the entire ecosystem respond faster.

On top of recent and ongoing support across our core platform and GitHub Copilot, we are also reaffirming our commitment to helping maintainers to secure their open source projects by announcing:

• GitHub Secure Open Source Fund is adding an additional $5.5 million in Azure credits and funding to provide training and expertise; community to improve outcomes; and new partners, including Datadog, Open WebUI, Atlantic Council, and OWASP.
• GitHub Security Lab is investing in the security advisory experience on GitHub and Private Vulnerability Reporting (PVR) features to reduce the burden of low-quality reports to help maintainers manage the increasing volume of security reports.

We have learned through programs like the GitHub Secure Open Source Fund that the most effective security outcomes happen when you link maintainer funding and resources to specific outcomes like improving security. After supporting 138 projects with over 200 maintainers across 38 countries, we have seen 191 new CVEs issued, 250+ new secrets prevented from leaking, and 600+ leaked secrets detected and resolved, impacting billions of monthly downloads from alumni projects. We also learned that providing hands-on coding with education and expertise, drives self-reported learning and action.

The outcome: when maintainers are empowered rather than overwhelmed, given time to learn with space to focus, and provided access to tools that fit naturally into their workflows, security improves for everyone downstream. This creates a community reinforcement flywheel. Those lessons shape everything we are doing next.

This work centers on helping maintainers defend and secure the projects that underpin the global software supply chain, at a time when AI is fundamentally changing both how vulnerabilities are discovered and how they are exploited.

Putting AI to work for maintainers

AI has dramatically increased the speed and scale of vulnerability discovery. That’s true for defenders and for attackers. Now, more than ever, maintainers sit on the front lines of software security. They often face a surge of automated pull requests and security reports with low signal-to-noise ratio. The result is increasing burnout.

As Christian Grobmeier, maintainer for Log4j, put it: “our AI has to be better than the attacking AI.” We agree. That is why our focus is not just on finding more issues. It is on helping maintainers triage, understand, and fix them effectively, without losing the joy or sustainability of maintaining open source. For example, our recent AI-powered security research framework was open sourced because we believe it should be used to empower maintainers and not only security teams.

Looking ahead, GitHub will continue investing in tools like pull request controls, while also ensuring AI is a force multiplier for maintainers from issue triage, pull request reviews, security vulnerability identification, and remediation, and more. It should not be another source of pressure. Maintainers of impactful open source projects already have access to Copilot Pro, which includes AI-assisted code review, agentic security remediation workflows, and access to a broad set of leading models all designed to help maintainers find and remediate risks faster.

AI should reduce maintainer burden, not increase it. Our goals are simple:

• Meeting maintainers where they already work on GitHub
• Helping prioritize actual issues over noise
• Accelerating fixes, not just findings
• Supporting secure defaults and healthy workflows

We will continue refining this alongside the community, informed by real world feedback and outcomes.

Open source is a shared responsibility

No single company or group can secure open source alone. The software we all depend on is built by a global community, and protecting it requires collaboration across ecosystems and global economies.

By working with maintainers and partners like Alpha-Omega, we aim to scale impact without fragmenting effort. By pairing GitHub’s platform, tools, and programs with shared community governance and trust, and providing maintainers with the latest models and AI-assisted coding tools, we can achieve this.

Most importantly, we are still committed to investing in people, not just projects. Because open source thrives when maintainers are supported, respected, and empowered to do their best work. We are grateful to every maintainer building the future with us.

Activate the tools available, and consider applying for GitHub Secure OSS Fund. Session 4 runs late April with each project receiving $10,000, Copilot Pro, $100K of Azure Credits, and 3 weeks of security education and a dedicated community. As always, your feedback helps shape what we build next.

The post Investing in the people shaping open source and securing the future together appeared first on The GitHub Blog.

The CDK Global breach exposed how niche vendors can cripple entire industries. Move beyond questionnaires to continuous, AI-driven monitoring of third-, fourth- and nth‑party dependencies, dynamic prioritization, and threat‑informed supply‑chain risk management.

The post The Silent Supply Chain: Why Your Fourth-Party Vendor is Your Biggest Blindspot  appeared first on Security Boulevard.

The open source ecosystem continues to face organized, adaptive supply chain threats that spread through compromised credentials and malicious package lifecycle scripts. The most recent example is the multi-wave Shai-Hulud campaign.

While individual incidents differ in their mechanics and speed, the pattern is consistent: Adversaries learn quickly, target maintainer workflows, and exploit trust boundaries in publication pipelines.

This post distills durable lessons and actions to help maintainers and organizations harden their systems and prepare for the next campaign, not just respond to the last one. We also share more about what’s next on the npm security roadmap over the next two quarters. 

Recent Shai-Hulud Campaigns

Shai-Hulud is a coordinated, multi-wave campaign targeting the JavaScript supply chain and evolved from opportunistic compromises to engineered, targeted attacks.

The first wave focused on abusing compromised maintainer accounts. It injected malicious post install scripts to slip malicious code into packages, exfiltrate secrets, and self-replicate, demonstrating how quickly a single foothold can ripple across dependencies. 

The second wave, referred to as Shai-Hulud 2.0, escalated the threat: Its ability to self-replicate and spread via compromised credentials was updated to enable cross-victim credential exposure. The second wave also introduced endpoint command and control via self-hosted runner registration, harvesting a wider range of secrets to fuel further propagation, and destructive functionality. This wave added a focus on CI environments, changing its behavior when it detects it is running in this context and including privilege escalation techniques targeted to certain build agents. It also used a multi-stage payload that was harder to detect than the previous wave payload. The shortened timeline between variants signals an organized adversary studying community defenses and rapidly iterating around them.

Rather than isolated breaches, the Shai-Hulud campaigns target trust boundaries in maintainer workflows and CI publication pipelines, with a focus on credential harvesting and install-time execution. The defining characteristics we see across waves include:

• Credential-adjacent compromise: Attackers gain initial footholds via compromised credentials or OAuth tokens, then pivot to collect additional secrets (npm tokens, CI tokens, cloud credentials) to expand reach. This enables reuse across organizations and future waves without a single point of failure.
• Install-time execution with obfuscation: Malicious post-install or lifecycle scripts are injected into packages (or dependency chains) and only reveal behavior at runtime. Payloads are often conditionally activated (e.g., environment checks, org scopes) and exfiltrate data using techniques tailored to the environment it is running in.
• Targeting trusted namespaces and internal package names: The campaign affected popular and trusted packages, and the worm published infected packages with existing package names. The second wave also patched the version number of the package to make the infected packages look like legitimate updates and blend in with normal maintainer activity.
• Rapid iteration and engineering around defenses: Short intervals between variants and deliberate changes to bypass previous mitigations indicate an organized campaign mindset. The goal is durable access and scalable spread, not one-off opportunism.
• Review blind spots in publication pipelines: Differences between source and published artifacts, lifecycle scripts, and build-time transformations create gaps where injected behavior can land without notice if teams lack artifact validation or staged approvals.

Recent waves in this pattern reinforce that defenders should harden publication models and credential flows proactively, rather than tailoring mitigations to any single variant.

What’s Next for npm

We’re accelerating our security roadmap to address the evolving threat landscape. Moving forward, our immediate focus is on adding support for:

• Bulk OIDC onboarding: Streamlined tooling to help organizations migrate hundreds of packages to trusted publishing at scale.
• Expanded OIDC provider support: Adding support for additional CI providers beyond GitHub Actions and GitLab.
• Staged publishing: A new publication model that gives maintainers a review period before packages go live, with MFA-verified approval from package owners. This empowers teams to catch unintended changes before they reach downstream users—a capability the community has been requesting for years.

Together, these investments give maintainers stronger, more flexible tools to secure their packages at every stage of the publication process.

Advice for GitHub and npm users and maintainers

Malware like Shai-Hulud often spreads by adding malicious code to npm packages. The malicious code is executed as part of the installation of the package so that any npm user who installs the package is compromised. The malware scavenges the local system for tokens, which it can then use to continue propagating. Since npm packages often have many dependencies, by adding malware to one package, the attacker can indirectly infect many other packages. And by hoarding some of the scavenged tokens rather than using them immediately, the attacker can launch a new campaign weeks or months after the initial compromise.

In the “References” section below, we have included links to longer articles with analysis of recent campaigns and advice on how to stay secure, so we won’t rehash all of that information here. Instead, here is a short summary of our top recommendations:

Advice for everyone

• Enable phishing-resistant MFA on all your accounts, particularly for GitHub package managers like npm, PyPI, RubyGems, or NuGet, and also any accounts that could be leveraged for account takeover or phishing, like email and social media accounts.
• Always set an expiration date on tokens to ensure that they’re rotated on a regular schedule. Organizations can enforce a maximum lifetime policy.
• Audit and revoke access for unused GitHub/OAuth apps.
• Use a sandbox, such as GitHub Codespaces or a virtual machine or container, for development work. This limits the access of any malware that you accidentally run.

Advice for maintainers

• Enable branch protection so that malicious updates cannot be pushed directly to your main branch, even if the attacker has access to a valid token.
• Use npm trusted publishing instead of tokens. Trusted publishing is also available for other package managers such as PyPI, RubyGems, and NuGet.
• Pin CI dependencies, enable code scanning, and don’t forget to resolve the code scanning alerts!
• Monitor package artifacts and validate published tarballs/bundles against source (e.g., SRI or artifact build attestations).

Note that the above advice is preventative. If you believe you are a victim of an attack and need help securing your GitHub or npm account, please contact GitHub Support.

References

• Report a malicious package in npm
• Our plan for a more secure npm supply chain
• Strengthening npm security
• View malware advisories in the Advisory Database
• Quickstart for securing your repository 
• Dependency review on GitHub
• OpenSSF best practices for npm
• Microsoft’s guidance for detecting and defending
• Recent improvements to GitHub Actions

The post Strengthening supply chain security: Preparing for the next malware campaign appeared first on The GitHub Blog.

Open source software is the bedrock of the modern software industry. Its collaborative nature and vast ecosystem empower developers worldwide, driving efficiency and progress at an unprecedented scale. This scale also presents unique vulnerabilities that are continually tested and under attack by malicious actors, making the security of open source a critical concern for all. 

Transparency is central to maintaining community trust. Today, we’re sharing details of recent npm registry incidents, the actions we took towards remediation, and how we’re continuing to invest in npm security.

Recent attacks on the open source ecosystem

The software industry has faced a recent surge in damaging account takeovers on package registries, including npm. These ongoing attacks have allowed malicious actors to gain unauthorized access to maintainer accounts and subsequently distribute malicious software through well-known, trusted packages. 

On September 14, 2025, we were notified of the Shai-Hulud attack, a self-replicating worm that infiltrated the npm ecosystem via compromised maintainer accounts by injecting malicious post-install scripts into popular JavaScript packages. By combining self-replication with the capability to steal multiple types of secrets (and not just npm tokens), this worm could have enabled an endless stream of attacks had it not been for timely action from GitHub and open source maintainers. 

In direct response to this incident, GitHub has taken swift and decisive action including: 

• Immediate removal of 500+ compromised packages from the npm registry to prevent further propagation of malicious software.
• npm blocking the upload of new packages containing the malware’s IoCs (Indicators of Compromise), cutting off the self-replicating pattern.

Such breaches erode trust in the open source ecosystem and pose a direct threat to the integrity and security of the entire software supply chain. They also highlight why raising the bar on authentication and secure publishing practices is essential to strengthening the npm ecosystem against future attacks.

npm’s roadmap for hardening package publication

GitHub is committed to investigating these threats and mitigating the risks that they pose to the open source community. To address token abuse and self-replicating malware, we will be changing authentication and publishing options in the near future to only include:

1. Local publishing with required two-factor authentication (2FA).
2. Granular tokens which will have a limited lifetime of seven days.
3. Trusted publishing.

To support these changes and further improve the security of the npm ecosystem, we will:

• Deprecate legacy classic tokens.
• Deprecate time-based one-time password (TOTP) 2FA, migrating users to FIDO-based 2FA.
• Limit granular tokens with publishing permissions to a shorter expiration.
• Set publishing access to disallow tokens by default, encouraging usage of trusted publishers or 2FA enforced local publishing.
• Remove the option to bypass 2FA for local package publishing.
• Expand eligible providers for trusted publishing.

We recognize that some of the security changes we are making may require updates to your workflows. We are going to roll these changes out gradually to ensure we minimize disruption while strengthening the security posture of npm. We’re committed to supporting you through this transition and will provide future updates with clear timelines, documentation, migration guides, and support channels.

Strengthening the ecosystem with trusted publishing

Trusted publishing is a recommended security capability by the OpenSSF Securing Software Repositories Working Group as it removes the need to securely manage an API token in the build system. It was pioneered by PyPI in April 2023 as a way to get API tokens out of build pipelines. Since then, trusted publishing has been added to RubyGems (December 2023), crates.io (July 2025), npm (also July 2025), and most recently NuGet (September 2025), as well as other package repositories. 

When npm released support for trusted publishing, it was our intention to let adoption of this new feature grow organically. However, attackers have shown us that they are not waiting. We strongly encourage projects to adopt trusted publishing as soon as possible, for all supported package managers.

Actions that npm maintainers can take today

These efforts, from GitHub and the broader software community, underscore our global commitment to fortifying the security of the software supply chain. The security of the ecosystem is a shared responsibility, and we’re grateful for the vigilance and collaboration of the open source community. 

Here are the actions npm maintainers can take now:

• Use npm trusted publishing instead of tokens.
• Strengthen publishing settings on accounts, orgs, and packages to require 2FA for any writes and publishing actions.
• When configuring two-factor authentication, use WebAuthn instead of TOTP.

True resilience requires the active participation and vigilance of everyone in the software industry. By adopting robust security practices, leveraging available tools, and contributing to these collective efforts, we can collectively build a more secure and trustworthy open source ecosystem for all.

The post Our plan for a more secure npm supply chain appeared first on The GitHub Blog.