Open Source Security in 2026: From Vulnerabilities to Trust

A digital illustration of a red shield with a lock symbol, representing cybersecurity and data protection, surrounded by circuit patterns and binary code.

Open-source software remains the backbone of modern digital infrastructure. In 2025, it also became one of the most consistently exploited attack surfaces. The reason was not a sudden spike in zero-days or developer negligence. It was a shift in how attackers operate.

The most consequential incidents of the past year exploited trust, not flaws.

Supply-chain attacks targeting open-source ecosystems demonstrated how compromised maintainer accounts, long-lived credentials, and automated build pipelines could be abused to harvest access at scale. 

Visual representation showing a digital padlock with a chain, overlaid with statistics about open-source code vulnerabilities in applications: 97% contain open-source code, 86% have known vulnerabilities, and 80% include high or critical-risk issues.

These campaigns often caused little immediate disruption, but enabled attackers to map environments, collect secrets, and return later with legitimate access.

By the end of 2025, one thing was clear: traditional application security models no longer scale.

What Changed in 2025

Several structural shifts defined the open-source security landscape:

  • Vulnerability disclosures reached record levels, while exploit timelines shrank to days or hours
  • Many high-impact incidents exploited known issues, stolen credentials, or trusted update paths, not novel vulnerabilities
  • npm and other ecosystems became focal points for malicious package activity and maintainer compromise
  • Public sector disruptions highlighted how shared platforms and third-party dependencies amplify blast radius

The lesson was not that visibility failed. It was that visibility without execution failed.

The Shift Heading Into 2026

As organisations move into 2026, open-source security is undergoing a fundamental reset.

Security will no longer be measured by how many vulnerabilities are detected. It will be measured by how effectively organisations can preserve trust, limit blast radius, and prove control in real time.

Several trends are already taking shape.

1. AppSec Becomes Software Supply Chain Security

Point solutions focused on scanning are being replaced by end-to-end approaches that span dependencies, containers, infrastructure-as-code, CI/CD pipelines, and build credentials. 

This convergence reflects how modern attacks unfold across the full delivery lifecycle, not within a single layer.

Diagram explaining failures of traditional AppSec models with four key points: periodic scans not reflecting real-time exposure, severity-based prioritization ignoring exploitability and usage, compliance evidence lagging operational reality, and manual remediation failing to keep pace with dependency churn.

2. Automated Fixing Moves to the Center

Manual remediation cannot keep pace with automated attacks. In 2026, fix-first security models and automated remediation are becoming the default, operating as an invisible layer that reduces risk without slowing development.

3. Regulation Drives Security Decisions

Regulatory frameworks such as the EU Cyber Resilience Act and NIS2 are shifting security investment from discretionary to mandatory. Organisations are increasingly expected to demonstrate timely remediation, secure-by-design practices, and auditable evidence of control.

“Security platforms that cannot produce machine-verifiable compliance evidence will increasingly fail procurement and audit requirements. Best-effort security will not satisfy fixed remediation deadlines. Automation becomes mandatory,” – Vivian Dufour, CEO at Meterian

4. SBOMs Are Necessary, But Not Sufficient

SBOM adoption continues to grow, but inventories alone do not prevent compromise. What matters is whether SBOM data is connected to enforcement, provenance verification, and remediation workflows.

5. Developer Experience Becomes a Security Control

Security tools that disrupt developers are bypassed. Tools that integrate quietly into existing workflows are adopted. In 2026, developer experience is no longer a usability concern — it is a security requirement.

6. Trust, Provenance, and Data Governance Take Priority

Recent supply-chain campaigns showed that attackers often harvest credentials and intelligence first, then exploit trust later. This elevates provenance, integrity, and governance of security data to board-level concerns.

The Question Leaders Must Answer

The defining question for 2026 is no longer whether another supply-chain incident will occur.

It is whether an organisation can respond faster than the attacker when trust breaks.

That response depends on automation, governance, and the ability to prove resilience continuously — not once a year, not after an incident.

Read the Full Predictions Report

This article captures only a portion of the findings from Meterian’s Open Source Security Predictions for 2026, which draws on 2025 attack data, public-sector incidents, and direct insights from Meterian’s CEO and CTO.

The full report explores:

  • Why supply-chain attacks are shifting toward reconnaissance and delayed exploitation
  • How regulation is reshaping open-source security strategy
  • What leaders must do in the next 90 days to reduce systemic risk

👉 Download the full Open Source Security Predictions for 2026 report to understand what’s changing — and how to prepare.

Open Source Security in 2026: From Vulnerabilities to Trust

PRESS RELEASE Meterian Issues Public Warning to UK Public Sector Following Recent Cyber Attacks on London Councils

London, UK — Dec 4, 2025


Meterian, a UK-based application security leader, today acknowledges the series of cyber attacks that have recently impacted several London councils, causing significant disruption to public services and exposing ongoing vulnerabilities within local government systems.

These attacks follow a prediction made earlier this year by Bruno Bossola, Meterian’s Chief Technology Officer, who accurately forecast the emergence of the supply-chain-based cyber threat that went on to disrupt organisations across multiple sectors. His analysis has now identified indicators of a new, more severe wave of attacks on the horizon, with public sector organisations likely to be primary targets due to their critical role and often complex digital estates.

“Public services are under unprecedented pressure,” said Bruno Bossola. “Our threat intelligence suggests that the recent breaches are only the beginning. A second, more sophisticated attack vector is emerging, and public sector organisations along with the Supply Chain must act now to strengthen their application security and supply chain defences.”

In response to the escalating threat environment, Meterian is extending support to all UK public sector organisations by offering complimentary trial access to its automated risk-scanning tool. This initiative aims to help councils, NHS Trusts, government departments, and other public bodies quickly identify vulnerabilities within their software supply chains and critical applications before attackers exploit them.

Through proactive, automated detection, repair, and continuous monitoring, Meterian provides organisations with an early-warning capability, something traditional penetration testing or annual audits cannot offer.

“Our mission is to help safeguard the UK’s critical infrastructure,” said the Meterian leadership team. “We recognise the pressure that councils and public bodies are facing. By making our scanning tool accessible, we aim to give the public sector the visibility and resilience needed to prevent the next attack rather than simply respond to it.”Public sector organisations interested in assessing their current risk exposure can register for a free 30-minute discovery call, during which Meterian’s specialists will guide them through the threat landscape and provide access to the scanning platform.

About Meterian
Meterian is a leading application security provider specialising in automated detection, remediation, and continuous monitoring of vulnerabilities within software supply chains. Trusted by organisations across finance, technology, and critical infrastructure sectors, Meterian delivers real-time insight and protection to help businesses stay ahead of emerging threats.

PRESS RELEASE Meterian Issues Public Warning to UK Public Sector Following Recent Cyber Attacks on London Councils

3 Lessons From APIdays London: Why OSS Visibility Matters

Open source powers most modern software and expands your attack surface. At APIdays London, Meterian CTO Bruno Bossola showed how a crafted JSON request can trigger remote code execution when a vulnerable dependency slips into a service. 

The key takeaway was that without visibility and fast remediation, vulnerabilities ride your software supply chain into production.

1) Exploits start upstream, not in production

Meterian’s live demo used a known jackson-databind flaw to execute code via a JSON payload. Incidents like the Apache Struts 2 breaches proved the same point years ago: attackers go where libraries are ubiquitous and exposure is public-facing.

Teams still discover many issues late, inside CI/CD or after release. By then, the vulnerable package is woven into multiple services and rollbacks get expensive.

What to change

  • Shift security into the IDE so developers see and fix dependency risk as they code.
  • Add pre-push and CI checks to block known-bad versions before they land on main.

2) You can’t patch what you can’t see

Most applications are a small slice of proprietary code on top of a large stack of third-party packages. New CVEs appear daily across NVD, OSV, and GitHub Advisories. If you don’t know exactly which versions you run—including transitives—you can’t assess blast radius or prioritise patches.


What good visibility looks like

  • Keep an up-to-date SBOM for every build (e.g., CycloneDX) and ingest vendor SBOMs.
  • Continuously monitor your dependency graph against live feeds and internal policy.
  • Prioritise RCEs and internet-exposed paths first, then reduce debt in lower-risk services.

3) Make remediation fast and routine

In the demo, upgrading a vulnerable component inside the IDE removed the exploit path in seconds. That’s the experience to aim for: actionable guidance at the moment of discovery, with one-click upgrades where possible. Speed reduces MTTR, avoids regressions, and prevents risk from spreading across repos.

Operationalise speed

  • Standardise one-click upgrades and automated PRs for safe versions.
  • Set patch SLAs by severity and exposure (e.g., 24–72 hours for critical RCEs).
  • Track MTTR, exception waivers, and policy drift to guide platform investments.

A simple workflow that works

  • IDE (shift left): real-time vulnerability assessment of manifests and transitive dependencies, with suggested fixes developers can apply immediately.
  • Pre-push: Git proxy hooks to enforce policy and block known-bad versions.
  • CI/CD: SCA checks per build, SBOM generation/signing, and fail-the-build on criticals.
  • Post-build: continuous monitoring of deployed SBOMs against new advisories; targeted rollouts for high-risk upgrades.
  • Governance: clear patch SLAs, exception process, and regular supply-chain reporting to leadership.

Bottom line

  • Exploit paths are simple; dependency graphs are not. Treat open source security as a first-class discipline.
  • Visibility is non-negotiable. If you can’t list it, you can’t fix it.
  • Shift left so the fastest path becomes the secure path—inside the IDE, at pre-push, and in CI.

Meterian’s  APIdays demo made it clear: build visibility, shorten the distance from detection to fix, and your software supply chain becomes measurably safer.

3 Lessons From APIdays London: Why OSS Visibility Matters

From Factory Floors to Software Stacks: Why OSS Risk Now Mirrors Physical Supply Chain Threats

Author: Rod Cobain • 5 min read

In the original piece, Mike Dwyer painted a vivid picture: Manufacturing Supply Chains Are No Longer Just Mechanical or Logistical Systems, they are deeply entwined digital ecosystems, where each ERP module, IoT-enabled actuator, and tier-2 supplier nodes can become an entry point for cyber threats. Logistics Matters Today, I want to push the conversation further: the open source software (OSS) layer now acts like a silent “sub-supplier” embedded within your tech stack, and like any hidden supply risk, it demands boardroom attention, not just the care of the development team. The risk of ignoring this is not just to your business but that of your customer and their suppliers.

Recasting Mike Dwyer: Resilience Is About More Than Hardware

The core message from Mike remains pivotal:

  • Cyber risk is business risk, it must be integrated across operations, procurement, R&D and logistics. How many times does this need to be repeated?
  • Legacy point solutions are no longer sufficient, resilience must be designed globally across tiers. This is a leadership situation.
  • Next-generation supply chains rely on intelligence, visibility, and agility,  but every “smart” layer you add is a new attack surface.

What often goes unsaid,  and is less visible to many manufacturers,  is how much of the “smarts” in these systems is built on open source software components. Every subsystem, from sensor drivers to data analytics modules,  often leverages OSS libraries. Thus, the same supply chain logic Mike describes must apply internally: your software dependencies are now your internal “suppliers.”

Meterian’s Warning: OSS Is Not Free from Risk. It’s a Source of Escalation Regardless of the business Size or Sector

Escalation Through the OSS Layer: A Multi-Tier Threat Model

Let’s examine how OSS risk can escalate, step by step, through any business sector:

  1. Developer/Subsystem Level
     A team integrates a third-party open source library (e.g. for analytics, messaging, or edge compute). Unknown to them, one of its transitive dependencies includes a known CVE.
     → That module becomes a foothold vulnerable to exploitation.
  2. Application/Subsystem Aggregation
     The vulnerable component is embedded in a subsystem (e.g. quality tracking, process control) that exposes APIs or networked endpoints. Attackers exploit the library flaw to gain code execution or escalate privileges.
     → What was a discreet bug becomes a path into a critical sub-system.
  3. Platform / Middleware / Integration Layer
     Multiple subsystems feed into central integration layers (e.g. MES, orchestration, data middleware). A malicious actor moved laterally from one compromised subsystem into the integration fabric.
     → The exploit travels across domains, bridging OT/IT boundaries.
  4. Control Systems / OT / Physical Assets
     From the integration layer, attackers may reach OT systems controlling PLCs, robotics, or sensors. Here lies real operational impact, production halts, manipulated outputs, or safety risks.
     → The breach translates into physical damage or downtime.
  5. Supply Chain / Partner Ecosystem
     If that platform is shared, or upstream/downstream partners rely on shared components, the exploit can spread further. A single OSS vulnerability could cascade throughout the partner network.
     → The domain of the breach finally becomes systemic, affecting multiple actors.

At each layer, the “supplier” is the embedded code you didn’t write, and if you haven’t been continuously verifying its integrity, the risk is already live.

Practical Steps: Embedding OSS Governance into Your Resilience Strategy

To fuse Mike Dwyer’s vision and Meterian’s warnings into actionable posture, here are recommendations:

FocusActions
Treat OSS like any other supplierMaintain an SBOM (software bill of materials) for all systems. Demand “security assurances” (e.g. scans, patches) from internal and third-party teams.
Integrate continuous SCA / vulnerability scanningEmbed tools like Meterian (or similar) into CI/CD pipelines such that builds with failing security scores are automatically flagged or blocked.
Prioritize remediation, not just detectionUse auto-remediation where possible, or triage by threat score, to avoid alert fatigue and ensure action. Meterian helps with guided upgrade paths.
Cross-functional awareness & trainingEmpower developers, ops, procurement, and leadership with visibility into OSS risk, and grant them the agency to act.
Threat modelling spanning software supply chainExtend your existing supply chain risk models to include internal “supplier layers” (OSS, SDKs) as nodes in your attack graphs.
Incident playbooks that assume internal code riskIn response planning, simulate OSS vulnerability scenarios, not just network intrusion, because in many modern attacks, the initial vector is a library exploit.

Final Thought: Resilience Demands Depth, Not Just Perimeter

Mike Dwyer’s assertion remains apt: supply chain security is business security. But the conversation must now extend inward: the OSS layer, once viewed as a cost-saver or innovation enabler, is a core battleground. Its risks escalate upward. A vulnerability at the bottom can ripple all the way to the executive level, halting production lines or worse.

It’s time to shift from reactive patching to anticipatory governance. Treat code like any other critical supplier, inspect it, test it, govern it, and don’t let your next downtime be the moment you realize the invisible layer was your greatest weakness. Are you aware that the UK Cyber Framework is in the spotlight and is seen as the standard to follow?

Stop ignoring the silent supplier. It’s time to manage your Open Source Risk in the modern supply chain and manufacturing tech stack. 

From Factory Floors to Software Stacks: Why OSS Risk Now Mirrors Physical Supply Chain Threats

Closing the Cyber Insurance Gap

Why Open-Source Scanning & Monitoring Are the Real Safety Net

3–4 minutes

Cyber insurance is the latest addition to the arsenal of tools in the fight against cyber-attacks, alongside Cyber Essentials and Pen Testing. Both in the business world and private life, we rely on insurance to cover day to day events  that disrupt our lives, but that safety net does not always meet expectations. The recent experiences of Jaguar Land Rover and the Co-op prove what many risk leaders already suspect: today’s cyber policies are riddled with exclusions and caveats that leave businesses exposed when it matters most.

In 2025 alone, we’ve seen:

Jaguar Land Rover (JLR) suffered a crippling cyberattack in September, shutting down production lines and disrupting suppliers worldwide.

  • Without a finalised cyber insurance policy, JLR is left absorbing the financial and operational fallout.
  • The Co-op, still reeling from its April cyber incident, disclose £206 million in lost revenue and an £80 million operating profit hit– much of which fell outside traditional insurance coverage.

Both stories highlight the same painful truth: insurance pays after the damage, if at all. Prevention pays every single time

A group of professionals seated around a conference table analyzing data on laptops and monitors, with red warning graphics displayed, emphasizing the message about cyber insurance and open-source monitoring.

The Fine Print of Cyber Insurance: What’s Not Covered

Insurers are increasingly cautious, excluding or limiting coverage in ways that reduce meaningful protection:

  • State-backed exclusions: Attacks deemed “nation-state” or “warlike” are carved out, leaving businesses to shoulder catastrophic losses.
  • Supply-chain blind spots: Most policies cover only direct IT damage, not the ripple effects when suppliers, logistics providers, or cloud vendors go dark.
  • Sublimits & carve-outs: Crisis PR, forensic costs, and even some business interruption claims often fall under restrictive sublimits.
  • Attribution battles: Proving causation can delay payouts for months, while revenue, reputation, and customer trust evaporate in days.

Why Open-Source Scanning & Monitoring Changes the Game

Insurance alone is not a resilience strategy. The real advantage comes from detecting, patching, and preventing threats before they escalate into claims. That’s where open-source scanning and monitoring deliver unparalleled value:

  • Transparency at scale: Unlike closed systems, open-source tools are frequently reviewed, tested, and enhanced by global communities, which means vulnerabilities have greater probability to be spotted and addressed by a larger community before they can be exploited.
  • Supply-chain visibility: Open-source monitoring illuminates risks across your ecosystem, from third-party code to vendor dependencies, directly addressing the blind spots excluded by insurance policies.
  • Cost-effective coverage: Deploying open-source scanning costs a fraction of insurance premiums, yet continuously reduces exposure, lowering both the frequency and severity of incidents.
  • Proactive compliance: Continuous monitoring demonstrates active governance, satisfying regulators, insurers, and boards while strengthening claims positions if an event does occur.
  • Actionable insights, not afterthoughts: Real-time alerts allow IT and security teams to act before attackers exploit weaknesses–something insurance simply can’t offer that.

Case Studies Reinforced: What JLR & Co-op Teach Us

  • Jaguar Land Rover’s disruption shows how missing insurance leaves organisations financially stranded. But even if cover had been in place, insurers likely would have contested or capped payouts under supply-chain or nation-state exclusions. Open-source monitoring could have identified weak points in advance, preventing stoppages before they cascaded through factories.
  • Illustrating the £206 million scale of business interruption, the Co-op’s loss shows that continuous monitoring would have been a better defense. Closing exploited vulnerabilities early would have shrunk the financial damage and allowed the company to bypass the time-consuming and ultimately low-yield fight over insurance claims.

Industry Recommendation: Build a Dual Shield

The modern cyber risk landscape demands a two-pronged defence.  This means having insurance to handle financial aftershocks, and moreover strategically deploying open-source scanning and monitoring to achieve real-time resilience by closing the specific exposure gaps that insurance explicitly leaves open.

In 2025, the winners won’t be those with the biggest insurance policy, but those who combine smart financial protection with relentless, transparent, and scalable monitoring.

Open-source scanning is far beyond a technical choice; it is a strategic investment. It empowers boards, reassures investors, and proves to regulators and customers that resilience is a measurable commitment, not just a buzzword.

Don’t just insure your cyber risk.  Shrink it–and maximise your operational stability.

Closing the Cyber Insurance Gap

Jaguar Land Rover Cyberattack: A Wake-Up Call for Supply Chain Resilience

3–4 minutes

The automotive giant’s recent cyber breach shows why continuous vulnerability assessment and open-source security are no longer optional.

Earlier this month, Jaguar Land Rover (JLR), the UK’s largest carmaker, was forced to shut down global IT systems after a cyberattack disrupted production across its factories. Plants in Solihull, Halewood, Wolverhampton, and Slovakia were halted. Operations in China, India, and Brazil also felt the ripple effect.

Thousands of employees and suppliers were sent home. Dealers and garages had to switch to manual operations during one of the busiest sales periods of the year: the September license plate registration window.

While no customer data breach has been confirmed, the attack reflects how deeply cybersecurity failures in the supply chain can damage both business operations and national economies. JLR contributes nearly 4% of the UK’s exports.

How the Jaguar Land Rover Attack Happened

The hacking coalition calling itself “Scattered Lapsus$ Hunters” claimed responsibility, posting internal screenshots as proof. Analysts link the group to earlier social engineering campaigns carried out by collectives like Scattered Spider, Lapsus$, and ShinyHunters.

This was not a sophisticated zero-day exploit. It was an attack on trust and resilience. By exploiting weaknesses in IT systems and operational processes, attackers triggered a shutdown that cascaded across JLR’s entire global network.

For an industry where every production hour counts, this was a direct hit to the supply chain.

Why Supply Chain Vulnerabilities Are a Critical Business Risk

The JLR case illustrates the stark reality:

  • Operational Technology (OT) systems are connected to IT systems. A breach in one disrupts the other.
  • Third-party risk is first-party risk. If suppliers or partners are compromised, your own resilience is at stake.
  • Downtime is as damaging as data loss. Even without stolen records, JLR faces millions in lost productivity and missed sales.
  • Open-source software is everywhere. Modern automotive systems depend on open-source libraries and components. Without continuous monitoring, hidden risks can remain undetected until it’s too late.

Where Vulnerability Assessment Makes the Difference

This incident is a powerful reminder of the need for continuous vulnerability assessment and software supply chain security. Key protective measures include:

  • Automated vulnerability scanning across all code, dependencies, and applications
  • SBOM (Software Bill of Materials) to ensure visibility into every open-source component used in critical systems
  • Continuous monitoring for newly disclosed CVEs that could disrupt supply chains
  • DevSecOps integration to ensure remediation is part of the development and deployment pipeline
  • Incident readiness through real-time alerts and automated remediation guidance

How Meterian Helps Build Resilience

Meterian’s platform is built to detect, monitor, and remediate open-source vulnerabilities before they cause widespread damage.

  • BOSS (Business Open Source Sentinel): Provides real-time alerts for newly disclosed vulnerabilities across your software supply chain.
  • Sentinel: Automates vulnerability assessment and integrates into your CI/CD workflows to block unsafe code before it reaches production.
  • SBOM generation and ingestion: Gives you complete visibility into the components your business depends on, simplifying compliance and response.
  • AI-powered continuous monitoring: Ensures you are always ahead of emerging threats—whether in PHP, Java, .NET, or any other stack critical to your business.

Had such systems been in place across JLR and its suppliers, the blast radius of this attack could have been contained, with faster detection and remediation.

Why Open-Source Security Matters

The JLR breach demonstrates a truth we see across industries: open-source security is business security.

When 80–90% of modern applications depend on open-source components, every unpatched library becomes a potential entry point. The cost of ignoring these risks isn’t theoretical. It’s operational paralysis, financial loss, and reputational damage.

Don’t Wait for the Next Breach

The JLR cyber attack is not an isolated incident. It is part of a wider trend of supply chain attacks targeting global industries. The question is not whether open-source vulnerabilities exist in your systems—they do. 

The question is: are you continuously monitoring and remediating them?

Now is the time to take control of your software supply chain.

👉 Learn how to strengthen resilience in our upcoming webinar:
“What’s Open Source Security Got to Do with Resilience of the Supply Chain?”
📅 September 18, 2025 • 14:00 BST • 15:00 CET • 09:00 ET • 18:30 IST

Register here

Jaguar Land Rover Cyberattack: A Wake-Up Call for Supply Chain Resilience

Major supply chain attack on the NPM ecosystem

by Bruno Bossola, initially published on LinkedIn on September 9, 2025. Republished here following second larger attack on November 24, 2025.

3–5 minutes
An illustration depicting various JavaScript code packages on a conveyor belt, with some showing green coding structures and others displaying red, corrupted code. Visible elements include digital threats such as skull icons and serpentine shapes representing malware, symbolizing a cybersecurity attack on software supply chains.

A number popular JavaScript code packages were compromised to spread malware, posing a significant threat to software supply chains. The malicious code, often obfuscated, was hidden within seemingly legitimate packages on the Node Package Manager (NPM) registry and executed during the installation process. This type of supply chain attack can lead to the theft of credentials, sensitive data, and even cryptocurrency.

How was the attack performed?

The attack on the debug and chalk packages was a sophisticated supply chain compromise that began with a phishing attack targeting the maintainer’s account. Attackers used a deceptive email, impersonating NPM support, to compromise the maintainer’s credentials. With access to the account, they published new versions of a number of popular JavaScript packages, including debug and chalk, with malicious, obfuscated code. This malware was a cryptocurrency stealer designed to run on a compromised machine, intercepting browser activity and targeting Web3 wallets. The malicious code would hook into network requests and use a fuzzy-matching algorithm to replace a user’s wallet address with an attacker-controlled one during a transaction, silently redirecting funds without the user’s knowledge.

What are the packages affected?

This is the current list at ~0830GMT on 09 September 2025:

How do I know if I am affected?

If you are using Meterian and have Sentinel enabled, you’ve been notified. Please make sure to remove the offending package or move to a non-affected version, and then quarantine the affected systems.

If you are using Meterian, you will also notice that your builds are failing. This is normal, as now Meterian detects a vulnerable package and brings down the security score: the moment such score goes below your threshold, then the Meterian analysis will report a failure

In general, developers should audit their codebases for affected packages, monitor network logs for suspicious activity, and stay vigilant against compromised open-source libraries. This incident underscores the critical need for robust security practices in the software development lifecycle.

If you are a developer and you want to check if you’re affected, you can use a simple grep command in your project folder, where the packages are installed:

grep -r "_0x112fa8"

A Phishing campaign is actively ongoing targeting NPM maintainers!

This is an example of an email received by maintainers from the fake npmjs.help domain, which was created for the sole purpose of performing this attack. If you are an NPM maintainer, please be aware and disregard these emails!

Also, the website is now marked as malicious everywhere and is being taken down as we speak. Well done OSS community!

Article content

But I checked and I did not see any malicious code on GitHub!

The difference you’re seeing is due to how npm packages are published.

When a developer publishes a package, they’re not necessarily publishing the exact code from their GitHub repository. Instead, they run a command, npm publish, which creates a compressed file (a tarball) of the project’s files and sends that to the npm registry.

A maintainer can manually modify the files within this tarball before publishing, or their build process could include a step that modifies or adds code, such as minifying or obfuscating it. Because this process happens locally and the resulting tarball is sent directly to npm, these changes might never be committed to the public GitHub repository. This is why the code you see on the npmjs.com website can be different from the code in the associated GitHub

I am running a backend service: am I affected?

The code first confirms it’s running in a web browser by checking for the window object. Once it verifies the environment, it hijacks common methods for network requests and cryptocurrency transactions, specifically window.fetch, XMLHttpRequest, and window.ethereum.request. It also targets other wallet provider APIs.

This means the malware is designed to steal from end users who have a crypto wallet connected to their browser. While developers aren’t the primary target, they can also become victims if they visit an infected site and have an active wallet.

While the malicious code is designed to be activated in a browser, it is still a significant security risk to your backend service. Even though the malicious payload itself may not execute on the server, the compromised packages introduce a backdoor into your dependency chain. The best practice is to immediately update or remove the vulnerable packages to eliminate the risk of a future, more targeted attack on your server.

What’s next?

We will keep updating this article following the evolution of this incident. If you did not do it yet, please consider adding some defence in your pipeline: Meterian users using Sentinel were alerted overnight of the issue.

Best of luck, stay safe!

Update: Read the follow on attack in our blog post from Nov 24, 2025 about Shai-Hulud 2.0 worm.

Major supply chain attack on the NPM ecosystem

SQL Injection is Back: A Critical ADOdb Vulnerability You Need to Patch Now

Following our recent alert about the PHP AVideo exploit (CVE-2025-48732), another high-risk vulnerability has emerged: ADOdb SQL Injection – CVE-2025-54419. This newly discovered open-source vulnerability in the ADOdb database abstraction library affects a wide array of PHP applications. And yes—it puts your customer database at serious risk.

Therefore, businesses must patch now, or risk customer data loss and brand damage.

Why This Vulnerability Matters

SQL Injection remains one of the most exploited classes of software flaws in today’s threat landscape. The ADOdb vulnerability (pre-5.22.9 versions) allows attackers to manipulate query inputs in PHP applications using SQLite3, enabling them to execute arbitrary SQL commands and:

  • Access sensitive customer data
  • Delete or modify database records
  • Compromise connected systems

This flaw exposes an all-too-common weakness in open-source software components. When dependency management fails, it’s your customer data and digital brand trust on the line.

What is ADOdb and Who Uses It?

ADOdb is a widely used open-source database abstraction library that enables PHP developers to write flexible applications that work across:

  • MySQL
  • PostgreSQL
  • Oracle
  • Microsoft SQL Server
  • SQLite
  • DB2
  • Sybase
  • Firebird
  • Access ODBC
  • Informix
  • And more…

It acts as the middleware connecting your PHP app to its data. In modern e-commerce, SaaS, and media delivery platforms, ADOdb often underpins customer records, inventory systems, and transaction logs.

Understanding the Vulnerability (Technical Breakdown)

This SQL injection vulnerability exploits three ADOdb methods:

  • metaColumns()
  • metaForeignKeys()
  • metaIndexes()

If these methods receive a malicious table name, SQLite3 fails to properly escape the input—leading to arbitrary SQL execution.

❗ A single malformed input can compromise your entire database.

This isn’t hypothetical. It’s a known weakness. And it’s now indexed across vulnerability databases. Attackers are already probing for this entry point.

Real-World Impact

Think of it this way: a customer attempts to view their order history. But due to a code-level vulnerability, the attacker uses that same request to exfiltrate entire user tables or drop your product catalog. This can result in:

  • Permanent data loss
  • Corrupted analytics and reports
  • System downtime
  • Compliance fines (e.g. GDPR, PCI-DSS)
  • Severe brand reputation damage

A recent IBM report noted that data breaches tied to open-source component vulnerabilities cost businesses an average of $4.45 million per incident in 2024.

What You Should Do Now

Here’s your quick vulnerability assessment checklist for ADOdb:

✔️ Does your application use ADOdb prior to version 5.22.9?
✔️ Are you using the metaColumns(), metaForeignKeys(), or metaIndexes() methods?
✔️ Are your PHP apps connecting to a SQLite3 database?
✔️ Have you scanned third-party dependencies for known CVEs?

If you answered “yes” or “not sure” to any of these, your platform is at risk.

Mitigate risk now with a software composition analysis (SCA) tool that identifies vulnerable open-source components and provides auto-remediation.

Meterian’s Take

At Meterian, our daily scans using BOSS and Sentinel detected and flagged this vulnerability as of August 5, 2025. Teams relying on Meterian’s continuous monitoring and automated vulnerability assessment tools received instant alerts and recommendations to patch or isolate affected components.

Learn How to Protect Your Software Supply Chain

Want to explore how continuous vulnerability assessment can protect your platform?

Join our webinar on September 18, 2025:
🛡️ What’s Open Source Security Got to Do with Resilience of the Supply Chain?

📍 Learn practical steps to secure your software supply chain
📍 Get insights from industry experts on real-world open-source risks
📍 Explore tools for automated remediation and SBOM management

👉 Register Now

Final Thoughts

SQL injection may seem like an old-school threat, but vulnerabilities like this one in ADOdb show that even trusted, mature packages are not immune.

Don’t assume your code is safe just because it compiles.🔍 Start your vulnerability assessment today. Use tools that continuously scan and remediate open-source security risks—before attackers breach your systems.

SQL Injection is Back: A Critical ADOdb Vulnerability You Need to Patch Now

Does Your Video Platform Have This Vulnerability? A Case for Proactive Vulnerability Assessment

In today’s digital-first economy, your brand story lives and breathes through video—from e-commerce product reels to customer testimonials and user-generated content. But what happens when the infrastructure behind that video platform becomes your weakest link?

A newly disclosed vulnerability in a popular open-source PHP platform is a clear reminder: routine vulnerability assessment is not optional. It’s the foundation for protecting both your customers and your brand’s digital identity. 

PHP: The Web’s Silent Workhorse and a Key Target

According to BuiltWith, PHP powers over 74% of the internet’s websites, including leading e-commerce platforms like Magento, WooCommerce, and Prestashop. These platforms handle millions in transactions and user data. Their popularity makes them prime targets for open-source security threats, particularly when dependencies and third-party components are not continuously monitored.

A 2024 report from IBM shows the average cost of a data breach now exceeds $4.35 million. But the real damage goes beyond financial loss—customer trust and brand reputation take the biggest hit.

The Exploit: CVE-2025-48732 in AVideo

The latest threat in this category comes from the wwbn/AVideo platform, which serves thousands of streaming and video hosting applications built in PHP.

  • CVE-2025-48732 is a critical-severity vulnerability (CVSS pending) caused by an incomplete blacklist validation for .phar files.
  • The flaw allows attackers to bypass upload restrictions and execute arbitrary code on the server.
  • The root cause? Improper handling of PHP archive files, which aren’t adequately blocked or validated.

This is a classic example of supply chain exposure through unpatched third-party libraries. Without proactive open-source vulnerability scanning, affected organisations remain blind to threats lurking in their dependencies.

We regularly analyse open source projects to identify security risks. The image below shows a short summary of the open source software library WWBN/AVideo, which has been found to have critical vulnerabilities.

Why Continuous Vulnerability Assessment Matters

This isn’t just about one vulnerability. It’s a wake-up call for all businesses using open-source frameworks to:

 ✅ Implement automated vulnerability assessment tools that scan your software supply chain in real-time
✅ Track emerging CVEs across your entire application stack
✅ Flag unsafe libraries and automatically suggest fixes
✅ Maintain a software bill of materials (SBOM) to understand your exposure footprint
✅ Integrate patching into your CI/CD pipeline for faster remediation

If your video platform or customer-facing application relies on AVideo, or any PHP component, you need a continuous security strategy to detect and resolve vulnerabilities before attackers strike.

Secure Your Platform Before It’s Compromised

At Meterian, we help teams detect and remediate vulnerabilities across their software supply chain through real-time open-source monitoring, automated remediation, and SBOM-driven visibility.

Want to know if your app is exposed to CVE-2025-48732?

Get a full breakdown of the AVideo vulnerability, exploit risks, and how to patch it now.
👉 Download our Security Report

Don’t wait to become the next headline. Stay ahead with intelligent, AI-powered vulnerability assessment.

Does Your Video Platform Have This Vulnerability? A Case for Proactive Vulnerability Assessment

Ivanti’s RCE Nightmare Started with a Library You Might Be Using Too

2–3 minutes

In May 2025, cybersecurity headlines were dominated by Ivanti Endpoint Manager Mobile (EPMM) facing active exploitation through chained remote code execution (RCE) vulnerabilities—CVE‑2025‑4427 and CVE‑2025‑4428. 

These flaws enabled unauthenticated attackers to execute malicious code on affected systems, affecting enterprises globally. Ivanti’s vulnerabilities were notably tied to outdated open-source Java components, highlighting the critical importance of managing open-source security dependencies.

In this blog, we explore the Ivanti incidents, understand the role vulnerable Java libraries played, and demonstrate how proactive software composition analysis (SCA), continuous monitoring, and automated remediation through Meterian-X could have prevented or swiftly mitigated these attacks.

Ivanti’s Open Source Vulnerability: Java Libraries at Fault

The Ivanti vulnerabilities were rooted in the software’s reliance on outdated versions of Java libraries, specifically including “hibernate-validator.” These libraries were susceptible to chained exploits:

  • CVE‑2025‑4427: Allowed authentication bypass.
  • CVE‑2025‑4428: Enabled subsequent remote code execution (RCE).

These vulnerabilities underscore a significant risk: even trusted enterprise products can expose businesses if they incorporate insecure or outdated open-source components.

Understanding the Attack Surface

Ivanti’s attack scenario reveals common industry oversights:

  • Outdated dependency versions not promptly updated.
  • Inadequate visibility into the software bill of materials (SBOM).
  • Insufficient integration of security checks in the continuous integration and continuous delivery (CI/CD) pipeline.

Given the rise in nation-state actors targeting supply chains, companies must ensure software dependencies are continuously scrutinized.

Continuous Monitoring & Detection with Meterian Sentinel

Meterian Sentinel actively monitors dependencies, aggregating real-time vulnerability intelligence from authoritative sources, such as the National Vulnerability Database and GitHub Security Advisories. 

Sentinel would have identified Ivanti’s outdated “hibernate-validator” dependency, alerting development and security teams of the urgent update required.

BOSS: Immediate Alerting & Automated Remediation

Meterian’s BOSS system provides:

  • Real-time notifications of critical vulnerabilities.
  • Actionable, prioritized remediation steps directly within development workflows.

In Ivanti’s case, BOSS would have immediately alerted to the risky dependency version, detailing the vulnerability and auto-generating a recommended fix within the CI/CD process.

Proactive Prevention: CI/CD Integration Workflow with Meterian-X

Integrating Meterian-X into CI/CD pipelines ensures software vulnerabilities are detected and addressed at the earliest stage, automatically:

  • Scanning: Meterian-X conducts real-time vulnerability scanning, flagging outdated dependencies like “hibernate-validator.”
  • Alerting: Via BOSS, teams receive instant alerts embedded within their existing development tools.
  • Remediation: Meterian-X auto-suggests safe library versions, ensuring secure deployment without manual intervention.
  • Verification: Automatically generates comprehensive SBOM reports (in CycloneDX format), streamlining compliance and software traceability.

This integration transforms vulnerability management from reactive firefighting into proactive security.

The Critical Role of SBOM

The Ivanti incident emphasizes why SBOMs are critical:

  • Manufacturers and enterprises gain transparent, real-time views into their software components.
  • Teams rapidly identify vulnerabilities within third-party dependencies.
  • Regulatory compliance becomes streamlined (e.g., SOC 2, EU CRA, EU DORA).

Meterian-X’s CycloneDX-based SBOM generation and ingestion is integral to maintaining visibility, security, and compliance.

Strengthening Your Software Supply Chain

Ivanti’s vulnerability illustrates a fundamental truth: security must extend beyond internal code to encompass all open-source dependencies. Meterian empowers security leaders, developers, and compliance teams to proactively detect and auto-remediate risks like those affecting Ivanti.

Adopting Meterian’s comprehensive security integration ensures continuous monitoring. It provides a rapid response and reliable protection of your software supply chain. This safeguards your business from the increasing threat of supply-chain-based cyber attacks.

Ivanti’s RCE Nightmare Started with a Library You Might Be Using Too