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.
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.”
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:
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.
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.
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.
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.
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:
Focus
Actions
Treat OSS like any other supplier
Maintain 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 scanning
Embed 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 detection
Use 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 & training
Empower developers, ops, procurement, and leadership with visibility into OSS risk, and grant them the agency to act.
Threat modelling spanning software supply chain
Extend 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 risk
In 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.
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
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.
Benefits, Risks, and Real-World Attacks Involving Open Source in the Insurance Industry
The insurance sector is undergoing a rapid digital transformation, integrating technologies like artificial intelligence, big data analytics, blockchain, and cloud computing to better serve customers, optimise operations, and reduce fraud. Central to this shift is the growing reliance on open source software (OSS), tools, libraries, and platforms freely available for development, adaptation, and integration. From talking to c-suite members within all of the key sectors, OSS is recognised as beneficial but also seen as the “elephant in the room” as the risks are known but lack of experience in dealing with this layer is allowing threat penetration to be successful
While OSS empowers insurers with flexibility, innovation, and cost efficiency, it also introduces serious cybersecurity risks. This article explores how open source is being used in insurance, outlining the real-world consequences of cyber threats involving OSS, and assesses the risks of future attacks, especially as threats grow more sophisticated.
Why Insurers Use Open Source Software
Open source components are now integrated into nearly every stage of the software development lifecycle in the insurance industry. Key benefits include:
Cost savings: Avoiding high licensing fees of proprietary software.
Faster development: Leveraging pre-built libraries and frameworks. This acceleration is exponentially magnified by AI coding assistants, which rapidly retrieve and integrate open-source snippets directly into developer workflows and push development cycles into overdrive.
Community support: Tapping into vast global expertise and frequent updates.
Flexibility: Extending existing open source code to meet business-specific requirements.
Examples include:
Apache Kafka and Airflow for real-time data processing.
TensorFlow for machine learning in fraud detection.
PostgreSQL and MongoDB for scalable data storage.
OpenJDK as a base for Java-based enterprise applications.
With open source software, legacy systems have been replaced. Insurance software providers have gained ready-to-use features and deliver enterprise-grade and SaaS applications 50-60% faster, while avoiding vendor lock-in. They are seizing the opportunity to be part of a sector-specific open source software community to learn, grow, and contribute, with potential to shape the future direction at a sector level. Some of these ready-to-use features include policy, claim, and property management, as well as time tracking. There are also templates available to offer embedded insurance products seamlessly integrated into customer buying experiences.
The business-led software-driven transformation helps streamline processes, enhance risk assessment, and improve customer service. We can all appreciate the availability of cloud-based solutions that’s increased the ease of purchasing standalone and embedded insurance products in our daily digital experiences. Forgot to buy travel insurance when you booked your ski holiday? Not to worry, because the ski rental agency that’s selling ski lift passes on their mobile web app also lets you buy insurance when you checkout. Open source software is helping to drive innovation and specialized offers across sectors, benefitting sellers and resellers from greater access to customers wherever they are in their journey.
OSS Cybersecurity Risks of Open Source within the Insurance Sector
Open source code, while powerful, is not immune to vulnerabilities. Many packages are maintained by volunteers, and while updates and patches are released very quickly, it’s difficult for a company to keep the pace, because of lack of awareness and processes to handle them. A single unpatched library can serve as a gateway to an entire corporate network, and for insurance companies, this can expose sensitive personal, financial, and medical data.
Key risks include:
Direct cyber attacks Because of the lack of vulnerability scanning, simply by leveraging an existing vulnerability in one opensource component used on an internet facing system, a hacker could get access to all internal databases.
Supply chain attacks A piece of malicious code included in a widely used software library is then automatically incorporated into thousands of downstream applications that use the library, allowing the attackers to compromise a vast number of targets simultaneously.
License mismanagement and IP risksWhen using a non-business friendly licensed component, there’s a significant risk of being forced to publicly release your own intellectual property, leading to loss of competitive advantage and potential legal action.
Shadow IT and undocumented OSS use The unmonitored use of unapproved software, often by developers seeking speed and agility, creates significant security and compliance blind spots, as these tools operate outside of corporate governance and lack security patching or vulnerability tracking
Notable Cyber Attacks Involving Open Source
1.Log4Shell (CVE-2021-44228) – Apache Log4j
In late 2021, a critical remote code execution vulnerability was discovered in Log4j, a widely used Java logging library.
Impact on insurance: Many insurance firms used Java-based enterprise systems that included Log4j, making them vulnerable.
Exploitation: Threat actors could remotely execute arbitrary code on affected systems. APT groups including Charming Kitten (Iran) and APT41 (China) were linked to active exploitation.
2.SolarWinds Supply Chain Attack
Though not directly OSS-related, this 2020 attack brought attention to third-party code risks, including OSS components.
Relevance to insurers: Many insurers use SolarWinds or similar IT management tools, and the incident led to an industry-wide audit of third-party dependencies.
3.MOVEit Transfer Exploits (2023)
Cl0p ransomware gang exploited zero-day vulnerabilities in MOVEit file transfer software, affecting dozens of insurance, healthcare, and finance companies.
Relation to OSS: MOVEit, while proprietary, included OSS components and APIs, showing how OSS can be an indirect vector.
Victims: Included Genworth Financial, a major life and mortgage insurer.
Known Named Threat Actors Targeting the Sector
DarkSide / BlackCat: Ransomware-as-a-Service groups frequently use software vulnerabilities, including in OSS, for initial access.
FIN11 / Cl0p: A ransomware group known for targeting insurance and financial companies.
APT38 (North Korea): Known for financial theft operations, including targeting SWIFT and related financial systems.
Lazarus Group: Has targeted healthcare and insurance sectors, possibly for both espionage and financial gain.
Future Threat Landscape: What’s Ahead?
The future risk to insurers from open source-based attacks is growing due to:
AI-driven vulnerability discovery tools used by threat actors.
Complex OSS supply chains making traceability and patching harder.
Open source CI/CD toolchains being exploited (e.g., Jenkins, GitLab CI).
Emerging Concerns:
Malicious open source packages: Attackers upload poisoned libraries to repositories like npm or PyPI. Example: “ctx” and “phpass” malicious packages.
Dependency confusion attacks: Exploiting package naming inconsistencies in private/public repositories.
Insider threats: Poor OSS governance can lead to accidental introduction of vulnerable or backdoored code.
AI-generated dependencies: As engineering teams increasingly rely on LLMs (Large Language Models) to write software, there is a high risk of ‘code hallucinations’ in which AI introduces outdated, unverified, or entirely fabricated open-source packages that serve as low-hanging fruit for attackers.
Mitigation Strategies for Insurers
Adopt SBOMs (Software Bill of Materials) Maintain a comprehensive inventory of all open source components in use.
Automated Vulnerability Scanning Use tools like Meterian, WhiteSource, or Dependabot to detect issues early.
Continuous Monitoring & Patching Establish DevSecOps pipelines to enforce regular OSS updates. This must also include guardrails around AI coding assistants to ensure that all AI-generated suggestions are scanned and vetted as rigorously as human-written code.
Zero Trust Architectures Prevent lateral movement even if a component is compromised.
Training & Awareness Developers should be trained on secure OSS usage and license compliance.
The AI Arms Race
The introduction of AI into the software development lifecycle has inadvertently triggered an arms race. Just as insurers use AI to accelerate development, threat actors are leveraging the exact same technology to weaponise open-source ecosystems at an unprecedented scale. Cybercriminals now use LLMs to rapidly scan massive open-source repositories for zero-day vulnerabilities, turning the speed of AI against defenders. Furthermore, attackers are automating the creation of highly convincing malicious packages, complete with fake documentation and GitHub histories. These are maliciously designed to trick AI coding assistants into recommending them. When a developer accepts an AI-generated code snippet that includes one of these poisoned dependencies, it creates a highly efficient, automated attack pipeline that brings malicious code directly into the heart of an insurer’s infrastructure.
Conclusion
The open source revolution has undeniably propelled innovation in the insurance industry. But this double-edged sword demands a proactive cybersecurity posture. From high-profile exploits like Log4Shell to the growing sophistication of supply chain attacks, it’s clear that OSS security is no longer optional, it’s critical.
Insurers must recognise open source as both an opportunity and a threat. Only through comprehensive risk management, visibility, and cultural change can they unlock its benefits while shielding themselves from cyber catastrophe.
If you’re in insurance, now’s the time to put OSS security on the boardroom agenda.
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
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
by Bruno Bossola, initially published on LinkedIn on September 9, 2025. Republished here following second larger attack on November 24, 2025.
3–5 minutes
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:
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!
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.
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 Sentineldetected 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?
📍 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
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.
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.
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.
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:
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.
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:
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.
In May 2025, a clone of the secure messaging app Signal — known as TM SGNL by TeleMessage — was compromised in under 20 minutes. The breach wasn’t due to zero-day exploits or state-sponsored threat actors. Instead, it was a plain, preventable Java server misconfiguration that exposed plaintext credentials, archived messages, and encryption keys.
This incident is a stark reminder for security and development teams – modern applications, especially Java-based clone apps, are riddled with hidden vulnerabilities that standard controls often miss.
This is exactly the class of threats Meterian’s continuous monitoring and AI-powered vulnerability intelligence is built to catch early and fix fast.
The TM SGNL Hack: Anatomy of a Misconfiguration
At the heart of the breach was a forgotten and publicly accessible Spring Boot Actuator endpoint. The exposed heap dump included:
Admin usernames and passwords in plaintext
Encryption keys
Archived private messages
TM SGNL had promised end-to-end encryption. Yet archived content was stored insecurely, and passwords were hashed using client-side MD5 — a deprecated and insecure method. The application also ran on an outdated JSP stack, compounding the risk.
The breach showed how vulnerable legacy Java frameworks and poor server hygiene can create systemic risk, even in apps that claim security by design.
Where Continuous Scanning Could Have Helped
This type of vulnerability isn’t exotic. It’s configuration-level, but critically dangerous. Meterian’s platform continuously scans Java applications for:
Misconfigured Actuator endpoints
Insecure or outdated hashing algorithms (like MD5)
Use of legacy Java stacks with unpatched CVEs
Exposure of credentials in memory dumps or logs
By aggregating insights from over 15 trusted vulnerability feeds, including the National Vulnerability Database and GitHub Advisories, Meterian flags risks with both high fidelity and low noise.
BOSS & Sentinel: Detect, Alert, Remediate
Meterian’s Sentinel engine would have flagged the publicly exposed /heapdump endpoint immediately as a misconfiguration with known exploit patterns. Combined with BOSS, our automated alerting system, security engineers would receive:
A prioritized, actionable report
A breakdown of the exposed endpoint’s risk level
Suggested auto-remediation steps (e.g., disable public access, require auth tokens)
These insights are delivered directly into existing CI/CD pipelines or DevSecOps dashboards, accelerating mitigation.
Why Java Clone Apps Are Especially Vulnerable
Clone apps often inherit:
Outdated codebases
Legacy dependencies
Minimal refactoring
In many cases, these applications rebrand functionality but retain insecure implementations. TM SGNL reused insecure design patterns while branding itself as a secure communications tool. This mismatch is where attackers thrive.
Meterian’s dependency graph analysis would have:
Mapped all third-party Java libraries in use
Flagged outdated dependencies
Identified insecure hashing libraries
What This Means for Security Leaders
Security isn’t just about patching CVEs. It’s about maintaining visibility and control across all components — including infrastructure, third-party libraries, and code hygiene.
Meterian helps CISOs, developers, and risk managers:
Maintain an up-to-date SBOM (using CycloneDX)
Integrate continuous monitoring into CI/CD
Detect vulnerabilities before they become breaches
Proactively secure clone apps before release
Prevention Is Achievable
The TM SGNL breach should not have happened. With continuous scanning, real-time intelligence, and automation-first remediation, it could have been prevented.
Meterian empowers software teams to spot and fix vulnerabilities like these — not weeks after deployment, but during development.
In 2025, security isn’t just a feature. It’s a process. And with Meterian, that process is invisible, continuous, and resilient by design.
