by Bruno Bossola, initially published on LinkedIn on September 9, 2025. Republished here following second larger attack on November 24, 2025.
4 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.
Red alert! All enterprise software maintainers of software using Java libraries need to check if their systems are affected by the newly discovered vulnerabilities “Spring4Shell” since its announcement, between 29th and 30th March, 2022, affecting various Spring components.
Vulnerability Score: 9.5 (CVSS:3.0 / AV: N / AC:L / PR:N / UI:N / S:U / C:H / I:H / A:H) Platform: Java Components: org.springframework:spring-beans Affected versions: all versions before 5.2.20, all versions before 5.3.18 Fixed in version: 5.2.20, 5.3.18
Please note that this affects also the spring-framework package and the spring-boot package, that both use the offending libraries. New versions of such packages have been made available. You can upgrade spring-framework to version 5.2.20 or 5.3.18, and you can upgradespring-boot to version 2.5.12 or 2.6.6 (note that spring-boot itself includes spring-framework, no other upgrades necessary).
Which systems does these affect?
CVE-2022-22963 affects any project built using a vulnerable version of Spring Cloud, a framework that provides tools for developers to quickly build some of the common patterns in distributed systems. The “functions” part is a subsystem used to implement serverless functions like AWS lambda or Google Cloud Functions: if you are using such subsystem you are potentially affected.
CVE-2022-22965 affects any project built using a vulnerable version of Spring Framework, Spring Boot or the library spring-beans. A successful attack, however, can only be conducted undere these conditions:
JDK 9 or higher is used as the runtime environment
Apache Tomcat is used as the Servlet container
The application is packaged as a traditional WAR (in contrast to a Spring Boot executable jar)
There is a dependency with spring-webmvc or spring-webflux, or an endpoint is used with DataBinder enabled
Please note however that analysis are undergoing and the nature of the vulnerability is quite general: we suggest you keep monitoring this page for further updates.
Why do these threats demand an urgent patch?
Both vulnerabilities allows the attacker to remotely execute code on your system, with the ability to gain complete control of the underlying servers. It’s a simple exploit, as it requires only to send a crafted HTTP header in a request in order to execute code on the remote host. These vulnerabilities are actively exploited in the wild.
How can I check if my system is affected?
If you maintain any software using Java libraries, check if you are using any Spring Cloud Function library. The Meterian BOSS scanner can be used to scan your codebase to identify all dependent software libraries. If it is using the offending package, it will find the affected vulnerable versions and provide more information on how to mitigate this risk.
If you are a developer and you have access to the code, you can simply execute this command from your terminal:
If you see any response lines, check the version: if it’s below 5.3.18 (as in the above example) or, if using 5.2.x, below 5.2.20, you may be affected.
My system has the vulnerable spring cloud function library — how can I mitigate the risk?
There are now patched versions of the affected components that resolve the issues, they are available via the standard Maven repositories. Upgrade the offending packages using the patched versions, as described in this article.
If the library is coming from a transitive dependency (it’s not one of your direct dependencies, but a dependency of them) you can just include an override in your root pom.xml (or where applicable) and retest that it’s not there anymore with the command shown before.
Please be aware that there are multiple packages rooted in "spring-cloud-function": you will need to upgrade all of them, in particular "spring-cloud-function-context" which is also directly affected.
Please be aware that you may need / may be better to upgrade the parent pom of the project using an unaffected version of spring boot / spring framework (see at the start of the article).
What can I do to proactively protect from such vulnerabilities?
We always suggest you regularly scan your software code bases.
To include this as part of your continuous improvement efforts to build resilience into your software development lifecycle, see our documentation on the various integrations we support with GitHub Actions, Azure DevOps Pipelines, and others.
Are Meterian applications affected by the spring vulnerability?
We have verified our applications and none are using the offending packages in a vulnerable configuration. We maintain a continuous monitoring system to ensure our development operations are up to date with the latest known vulnerabilities in software components. Given the nature of this vulnerability we will be running a specific monitoring for the following days, while more details are unfolded in regards to those vulnerabilities.
We are sure many of you have been hearing about SBOMs. Nowadays, software include some components with code written by your own developers, but 80-90% of the code is typically from third-party developers. How can you know who produced what and when it absolutely needs to be replaced? Since Meterian has been managing SBOMs for awhile, we’re happy to share our know-how so you can consider a comprehensive strategy to manage your open source software supply chain.
SBOM is an acronym that means Software Bill Of Materials. The concept originates from the manufacturing industry, where a bill of materials lists dependent components in machinery. A SBOM lists all third-party components present in your application. A good SBOM also lists the licences used by each component and, when possible, the specific copyright attribution. An excellent SBOM can also provide further information, such as possible relationships between those components to better understand any supply chain risk. You may have encountered SBOMs in the past, known as “third party notice” documents created to manage legal requirements, such as the one in the image below.
However, modern SBOMs are “machine-readable”. They follow a strict specification that can be understood by a computer.
What machine-readable formats are used to publish SBOMs?
The most commonly used formats to define a SBOM are:
CycloneDX, a lightweight open-source standard designed for use in application security context and supply chain component analysis. This originated from within the OWASP community.
SPDX, an open source format with origins in the Linux Foundation, slightly more complex, and recently approved as ISO/IEC standard in version 2.2.1 as ISO IEC 5962:2021.
SWID, another ISO/IEC industry standard used by various commercial software publishers.
All these formats support a variety of use cases, but the first two (CycloneDX and SPDX) are the most versatile. Due to SPDX’s complexity, we think CycloneDX has an edge at this time, but only time can tell which of these formats will be the winner. To learn more about these formats you can also read the official NTIA publication, which drills down into the matter.
Why are SBOMs important? And how are they useful?
As a consumer of software, the main reason why you want to have access to the SBOMs of the systems you are using is to manage risks. When a very commonly used software component becomes vulnerable: how do you know what you need to patch and which subsystems are at risk? This is exactly what happened with the recent Log4Shell debacle. The logging library called Log4j, was suddenly exploitable with a very simple and repeatable attack. How do you know where it is? Which one of the systems you are using is suddenly at risk? With a correctly managed archive of SBOMs, getting this information reduces to a very simple lookup task. Without it, it can be a real nuisance —a time consuming information hunt that disrupts everyone’s work flow.
As a producer of software, instead, you want to preserve and maintain an archive of all the SBOMs of the system you produce so that you can create and distribute timely patches to your customers. Having a systematic and comprehensive analysis of your most commonly used software packages would be useful indeed. Some companies were very fast in releasing patches to their customers, while others were extremely slow, mostly because they did not have the information. You probably want to be in the first group of companies 🙂
Governments are also mandating the need for use of SBOMs, realising that software security needs to be regulated. The U.S. Executive Order 14028 that mandates all federal agencies to require SBOMs from their suppliers. This not only impacts the companies that have direct sales to the US government but also their own software suppliers. As so many systems and devices have been connecting to the Internet to send and receive information, consequently our digital world relies on a software supply chain. This “ripple effect” will be significant for many industries.
Very carefully :), because an SBOM contains the full list of the “ingredients” of your system or application. While open-source projects happily share this information to the world, the same does not apply to private companies. In fact, a malicious actor that gets hold of the SBOM of your system can then check if you are using any vulnerable components. There are public vulnerability databases, such as the NVD, which are very popular. Someone can simply browse in there and compose a list of possible attacks, try them, and maybe get lucky. Probably 9 out of 10 vulnerabilities affecting components in your system won’t be exploitable, but having the ability to go through the whole list, certainly makes the task of finding an exploit much easier.
There’s no need to keep SBOMs a complete secret, however, as long as a few simple principles are kept in check:
SBOMs need to be shared securely,
they need to be accessed only by the authorised parties, across organisational boundaries, and
they should not be tampered with.
In summary, it is essential to produce a precise SBOM, and it is just as vital to share it and maintain it securely with the correct (trusted) third parties.
Why bother with SBOMs now?
In summary, it is essential to produce a precise SBOM, and it is just as vital to share it and maintain it securely with the correct (trusted) third parties. In our hyper connected world, comprehensive coverage of components is important for preventative strategies and threat detection in supply chain attacks. Therefore, implementing SBOM management proactively now will be worth something to your organisation when the next critical vulnerability appears and stand your organisation in good stead. All good collections are worth organising. How valuable is your collection of software?
The need for SBOMs is already high. Level up your open source software security and implement this requirement. Check out the SBOM capabilities in Meterian-X platform’s approach to DevSecOps.
This is a call to arms. All enterprise software maintainers of software using Java libraries need to check if their systems are affected by the newly discovered Apache Log4j vulnerability since its announcement on Dec 9, 2021. Since then several security vulnerabilities in the wild have been discovered.
Vulnerability Score: 6.6 (CVSS: 3.0 / AV: N / AC: L / PR: N / UI: N / S: C / C: H / I: H / A: H) Platform: Java Component: org.apache.logging.log4j:log4j-core Affected versions: 2.0-alpha7 to 2.17.0 inclusive, except 2.3.2 and 2.12.4. Fixed in version: 2.17.1
Vulnerability Score: 10.0 (CVSS: 3.0 / AV: N / AC: L / PR: N / UI: N / S: C / C: H / I: H / A: H) Platform: Java Component: org.apache.logging.log4j:log4j-core Affected versions: all versions before 2.14.1, inclusive Fixed in version: 2.15.0 but upgrade to 2.17.0 is required because of CVE-2021-45105
Vulnerability Score: 9.0 (AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H) (updated 18/12/2021) Platform: Java Component: org.apache.logging.log4j:log4j-core Affected versions: all versions up to 2.15.0, excluding 2.12.2 Fixed in version: 2.16.0 but upgrade to 2.17.0 is required because of CVE-2021-45105
Vulnerability Score: 7.5 (CVSS: 3.0 (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H) Platform: Java Component: org.apache.logging.log4j:log4j-core Affected versions: all versions from 2.0-beta9 to 2.16.0, inclusive Fixed in version: 2.17.0
Which systems does this affect?
Apache Log4j is probably the most common library used for logging in the Java ecosystem with over 400,000 downloads from its GitHub project. It is used in Java applications to log system and user activities, so there’s a serious possibility your Java software is using it. It is used, internally, by many other Apache frameworks such as Apache Flink, Apache Druid, Apache Flume, Apache Solr, Apache Flink, Apache Kafka, Apache Dubbo. It is also actively used in many other open source projects, like Redis, ElasticSearch, Elastic Logstash, Ghidra and many others.
Among all these open source components, one needs a special mention: Apache Struts. Yes, it is actively using Log4j. There exists a potential to trigger high-impact attacks against a wide variety of apps and services, similar to the scale witnessed in 2017. At that time, due to the vulnerability exploited in the Equifax megahack, 140 million customers’ data in North America and UK were breached. The latest version of Apache Struts, 2.5.28, uses by default Log4j version 2.12.21, which is vulnerable to this attack. This time, however, the scope for damage could be even wider, as Apache Struts is one of many Apache frameworks that use Log4j.
The Java ecosystem is in very broad use in enterprise systems and web apps and many mainstream services are likely to be vulnerable. Therefore, software maintainers and developers should pay close attention to this vulnerability.
This has been preliminary filed as CVE-2021-44228, and a subsequent vulnerability was also flagged, now filed under CVE-2021-45046.
Why does this threat demand an urgent patch?
This vulnerability allows the attacker to remotely execute code on your system, with the ability to gain complete control of the underlying servers.
This is actively exploited on the internet now and there is already a simple POC (proof of concept) available on the internet that explains how to do it.
“All an attacker has to do to exploit the flaw is strategically send a malicious code string that eventually gets logged by Log4j version 2.0 or higher. The exploit lets an attacker load arbitrary Java code on a server, allowing them to take control. […]Minecraft screenshots circulating on forums appear to show players exploiting the vulnerability from the Minecraft chat function. On Friday, some Twitter users began changing their display names to code strings that could trigger the exploit. Another user changed his iPhone name to do the same and submitted the finding to Apple. Researchers told WIRED that the approach could also potentially work using email.”
If you maintain an enterprise system using Java software, you would need to update all affected applications, whether they are maintained directly by your organisation or your supplier organisation.
Within 2 days of the 2017 vulnerability being announced, several systems around the world were breached by exploiting the software weakness. We do not want more cyber breaches of such scale and all need to react quickly to patch vulnerable systems.
How can I check if my system is affected?
If you maintain any software using Java libraries, check if you are using Apache Log4j. Meterian BOSS scanner can be used to scan your codebase to identify all dependent software libraries. If it is using Log4j, it will find the affected vulnerable versions and provide more information on how to mitigate this risk.
If you are a developer and you have access to the code, you can simply execute this command from your terminal:
If you see any response lines, check the version: if it’s below 2.16.0 (as in the above example) you may be affected.
My system has the vulnerable log4j library — how can I mitigate the risk?
There is a patched version of the library that resolves the issue. Released by Apache Software Foundation, the solution is to immediately upgrade log4j to the latest log4j version 2.16.0. The fixed version is available via Maven.
If the library is coming from a transitive dependency (it’s not one of your direct dependencies, but a dependency of them) you can just include an override in your root pom.xml (or where applicable) and retest that it’s not there anymore with the command shown before:
A set of mitigations, specific to the version you are using, are also available on the Apache Log4j website. The Apache Struts team provided specific advice on how to handle the issue.
If you are using an external product that runs with Java, you can also protect your systems by launching the JVM with this special parameter:
-Dlog4j2.formatMsgNoLookups=true
This is useful for tools like Jenkins, where you have control of the installation but you do not have control of the code, but please note that this does not protect against the latest CVE.
What can I do to proactively protect from such vulnerabilities?
We always suggest you regularly scan your software code bases.
To include this as part of your continuous improvement efforts to build resilience into your software development lifecycle, see our documentation on the various integrations we support with GitHub Actions, Azure DevOps Pipelines, and others.
Are Meterian applications affected by the log4j vulnerability?
No. We have verified our applications and none are using log4j. We maintain a continuous monitoring system to ensure our development operations are up to date with the latest known vulnerabilities in software components.
The topic of sustainability is unmissable at the moment. As the urgency of the situation grows, it continues to demand attention from various sectors and industries within society. You may wonder where the cyber security industry fits into all of this. Whilst traditionally from very different worlds, they are united through the characteristics of constant innovation and the capacity to bring about real change for the better. Certainly, cyber security has a bigger role to play in the overarching battle for a more sustainable world than one may initially think.
The Industry
As around two thirds of greenhouse gas emissions world wide are associated with burning fossil fuels1, renewable energy is a good place to start. The UK currently has the largest number of offshore wind resources in the world, equating to about 10GW in operation outside of the border2. Infrastructure such as this pushes us one step closer to meeting the UK’s target of reaching net zero emissions by 20502. It’s not just the UK that has set the ball rolling in the fight against greenhouse emissions, our friends across the pond are aiming for no electricity sector carbon emissions by 2035— as outlined by Biden3. So, whilst this growing industry means great things for our hopes of preserving the world we live in, mass investment means it is also shaping up to be a very lucrative market for cyber criminals to direct their efforts towards. Jim Guinn, global managing director for cyber security in energy, chemicals, utilities and mining at Accenture states, “The cybersecurity conversation in the renewable energy engineering and construction business is almost nonexistent today.”3 It is imperative that an industry gaining traction as quickly as this one protects itself with the necessary defense measures against cyber attacks.
How exactly are renewable energy plants made vulnerable to cyber hackers?
As mentioned before, sustainability shares close ties with new innovation. Renewables depend on control systems and distribution networks supported by technology. As many sources of renewable energy, such as wind and solar power are not readily available 24/7 like fossil fuels are— they require storage previsions that are also underpinned by technology4. IoT plays a huge role in the remote monitoring, control and regulation of off-shore wind turbines5. As we know, more than 75% of the code in use that makes these technologies a reality is open source, putting open source components smack bang in the middle of the sustainability conversation. However, older wind farms and their communication systems were never designed with the “security by design” mindset like the IEC 62443 standard6, similar to the GDPR principle7. As stated by Jim Guinn “renewables have lax cybersecurity standards, as they are an industry that may be more focused on building first and leaving cybersecurity as an afterthought”3.
Past attacks
A first example in which renewable energy facilities became victims of cyber attacks was the 2014 DragonFly hack8. The cyber criminal group used Remote Access Trojans (RAT) named Backdoor.Oldrea and Trojan.Karagany to infiltrate energy grid operators, major electricity generation firms, petroleum pipeline operators, and Energy industry industrial control system (ICS) equipment manufacturers located in the United States, Spain, France, Italy, Germany, Turkey, and Poland. The hackers had been present in systems since 2011 before detection. Although reports indicate that the overarching aim of the hack was to gather intelligence, later investigation suggested it also had the capacity to take control of physical systems themselves.
A second example in which renewable energy facilities have fallen victim to cyber attack was the SPower hack of 2019. Unfortunately, the group gained the title of being the first U.S. provider of solar and wind renewable energy to have been the victim of a cyber-attack. A hacker used a vulnerability in a Cisco firewall to interrupt the connection between sPower’s wind and solar power generation installations and the company’s main command center9.
More recently, Colonial Pipeline’s hack10– reported on 7th May 2021 fell victim to a cyber attack, highlighting just how seriously energy supplies can be affected by cyber criminal organisations. As a result of ransomware, one of the U.S’ biggest pipelines was forced to shut down operations11. In the subsequently released statement it was revealed that after a 90M bitcoin payout, Colonial Pipeline said that remediation is ongoing and each system is being worked on in an “incremental approach”12. This attack compromised around 45% of the East Coast’s fuel, including gasoline, diesel, home heating oil, jet fuel, and military supplies. Whilst the energy jeopardised in this case was not renewable, Jonathan White, director of NREL’s cybersecurity program office highlighted that “As the penetration of renewable generation and EV charging stations increases in the future, the consequence of a successful attack is likely to be similar in aggregate to those of a successful attack to a natural gas, coal or nuclear plant today”3. Thus, a cyber attack such as the one launched on Colonial Pipeline gives a worrying insight into the potential damage that could be launched on the renewable energy sector.
Risks for the future
After using the Meterian web scanner to evaluate the security of some major UK energy suppliers, we were able to see that similar issues are being faced. For example, the UK’s biggest supplier of energy, British Gas received a security score of 0 out of a best possible 100. Our report indicates that they currently have components in use that pose a threat to their system, as well as components in use with undeclared licenses.
Again, after scanning https://firstlightfusion.com/, one of the UK’s leading renewable energy suppliers, we found 2 high threat level vulnerabilities and 3 medium threat level vulnerabilities, as well as components in use with undeclared licenses.
As this sector grows in both relevance and monetary value, there is a need for adequate cyber security that is growing in unison. According to industry growth trajectories, the renewable energy sector is set to become a big target of cyber hackers. As shown in this blog, experts have not been afraid to warn that more needs to be done to reinforce the security of renewable plants. The need is made even more important to protect consumers’ faith in new energy sources that play an important role in our fight against climate change.
There is some evidence that the tide is changing to benefit the cybersecurity of the energy sector, both traditional and renewable. On 12th May 2021 Biden issued The Executive Order on Improving the Nation’s Cybersecurity13. A few main points from the bill are:
New and more stringent cyber security standards for government purchased software including multi-factor authentication and endpoint detection and response of software.
Suppliers of technology must provide a SBOM (Software Bill Of Materials) that highlights the source of the software (supplier ID) that can be used to perform a risk assessment. This supplier ID can be used to alert high risk software if it is not verified by the digital signature applied to a SBOM14.
There is to be the enforced sharing of intel surrounding cyber attacks, in the hope that the sharing of information will benefit us all. Jennifer Bisceglie, President and CEO of enterprise resilience company Interos Inc., stated that “we live in a world that people are, and companies are very concerned about their brand and reputation”15 and thus are reluctant to admit to cyber breaches. The new bill is set to remove fear of blame and shame and promote collaborative learning and continuous improvement for a safer and stronger society in the digital world.
An automatic, continuous line of defence protecting the open source components in use in renewable energy control systems is one way that Meterian can support the ongoing battle against carbon emissions. Whilst incremental in their support of rapid innovation, open source components are a pressure point to security systems of which cyber attackers are not afraid to make use of.
Visit our homepage to learn more about how Meterian can secure your businesses’ open source components—keeping cyber hackers out and your intellectual property in.
1 “Energy and climate change”. European Environment Agency, 11 May 2021, https ://www.eea.europa.eu/signals/signals-2017/articles/energy-and-climate-change
2GOV.UK, 6 October 2020, https ://www.gov.uk/government/news/new-plans-to-make-uk-world-leader-in-green-energy
3 Vasquez, Christian. “CYBERSECUIRTY: Biden is eyeing renewable energy. So are hackers”. E&E News, 22 December 2020, https ://www.eenews.net/stories/1063721291
4 Ruhle, Micheal and Trakimavicius, Lukas. “Cyberattacks are the new challenge for renewable energy”. Politico, 18 July 2017, https ://www.politico.eu/article/opinion-cyberattacks-are-the-new-challenge-for-renewable-energy/
5 Taylor-Smith, Kerry. “How IoT can improve the performance of offshore windfarms”. NS Energy, 15 May 2020, https ://www.nsenergybusiness.com/features/iot-wind-power/
6 Freudenberg, Wolf K. “Why windfarms need to step up cyber security”. DNV, https ://www.dnv.com/article/why-windfarms-need-to-step-up-cyber-security-128082.
9 Cimpanu, Catalin. “Cyber-attack hits Utah wind and solar energy provider”. ZDNet, 31 October 2019, https ://www.zdnet.com/article/cyber-attack-hits-utah-wind-and-solar-energy-provider/
10 “Colonial Pipeline confirms it paid $4.4m ransom to hacker gang after attack”. The Guardian, 20 May 2021, https ://www.theguardian.com/technology/2021/may/19/colonial-pipeline-cyber-attack-ransom
11 Galiordi, Natalie. “Colonial Pipeline aims to restore operations by end of the week after cyberattack”. ZDNet, 10 May 2021, https ://www.zdnet.com/article/colonial-pipeline-aims-to-restore-operations-by-end-of-the-week-after-cyberattack/
12 Stevens, Pippa. “Owner of pipeline shuttered by cyber attack aims to restore service by end of the week”. CNBC, 10 May 2021, https ://www.cnbc.com/2021/05/10/colonial-says-parts-of-fuel-pipeline-being-brought-online-aims-to-restore-service-by-end-of-week.html
13The White House, 12 May 2021, https ://www.whitehouse.gov/briefing-room/presidential-actions/2021/05/12/executive-order-on-improving-the-nations-cybersecurity/
14 Brooks, Richard. energycentral, 21 May 2021, https ://energycentral.com/c/ec/cybersecurity-executive-order-requires-new-software-security-standards-synopsys
15 Roby, Karen. MSN, “Expert: Biden’s executive order on cyber security is a good start toward protecting organizations”. 26 May 2021, https ://www.msn.com/en-us/money/smallbusiness/expert-bidens-executive-order-on-cybersecurity-is-a-good-start-toward-protecting-organizations/ar-AAKnd7E?ocid=uxbndlbing
Here we are! Guess what’s vulnerable again? On April 10th 2020 it was made public that a vulnerability has been exploited in the most popular Javascript library ever implemented: jQuery 3.4.1.
Why is jQuery 3.4.1 vulnerable?
Vulnerability score: 5 Platform: Javascript Components: jQuery, all versions before 3.5.0
When jQuery is invoked, it reads the HTML document and returns requested fragments of it. Now, while reading the document it might find that the one or more requested fragments are not in the correct format, so it tries to translate them. Although most of the times the translation is correctly performed, it’s been demonstrated that in particular cases the conversion (or parsing) could lead to an XSS cross-site scripting vulnerability.
An XSS cross-site scripting is a type of code vulnerability that allows attackers to insert malicious code into the web pages viewed by other users. It might be exploited to steal information such as access tokens or other sensitive information. This is what a criminal or Black Hat hacker would do.
This is what a criminal or Black Hat hacker would do. White Hat hackers, on the other hand, would behave ethically and use their software White Hat hackers, on the other hand, would behave ethically. Using their software engineering knowledge, White Hat hackers would show how to exploit a vulnerability: publish useful information about it to make sure both users and owners of the vulnerable library could take actions to prevent attacks.
What actions are required to safely update?
The first thing to know is that all the old versions of jQuery have some sort of vulnerability. Up until April 10th, version 3.4.1 was the only safe version available. Fortunately, the new minor release 3.5.0 has been published to fix the XSS security vulnerability.
As suggested in the jQuery release note, updating to this latest version might break your code as, to prevent the abuse of this vulnerability, the HTML element phrase is no longer converted. Therefore, a code review might be in order.
There is a lot of time-consuming effort involved in staying on track with all the latest code vulnerabilities as they are discovered but, fortunately, Meterian can help you with that.
When added to the CI/CD pipeline of any application, Meterian will automatically detect such vulnerabilities, or even fix them for you, and it will help you avoid the risk of an attack before it becomes a problem.
Welcome back to Meterian’s next Vulnerability Focus report edition. This week we are talking about Javascript vulnerabilities which need to be addressed. Both have been published in recent months and have a medium severity threat. The first vulnerability could result in a cross-site scripting attack whilst the second is to do with a cryptographic issue. There are over 1.6 billion websites in the world, and JavaScript is used on 95% of them, be sure to check if you could be affected.
CVE-2019-12043: there is a vulnerability in remarkable 1.7.1 affecting the unknown processing in the library lib/parser_inline.js of the component URL Handler. Manipulation of this component can lead to cross-site-scripting.
CVE-2019-9155: OpenPGP.js has a cryptographic issue which could allow attackers to conduct an invalid curve attack and gain the victim’s ECDH private key
Read up Javascript users! This vulnerability was posted last year in 2019, yet because of the significant amount of people using Javascript for their web apps, we thought it would be useful to inform people who might not have had time to address the issue.
This vulnerability has been found in remarkable 1.7.1 and is considered problematic. The component mishandles URL filtering, which allows attackers to trigger an XSS attack via unprintable characters.
Cross site scripting is an injection of malicious code into a trusted web app. As described above, this happens when the user input is not sufficiently validated either on the client or server side. The scripts injected will have malware which then allows the hacker to do a series of exploits. What is more concerning is that the attack could then alter the appearance of the web app and also commence attacks on users visiting that site.
This Javascript vulnerability was published in September 2019 and has a medium severity score of 5.9.
The vulnerability is a cryptographic issue in OpenPGP.js up to and including 4.2.0. This is a library in Javascript and therefore can be used on nearly any device. Users do not have to install a gpg on their machines in order to use this library, and therefore it can be reused in other projects that have browser extensions or server apps. Its main function is to sign, encrypt, decrypt and verify any kind of text, specifically emails.
The problem allows hackers, who can provide forged messages and get feedback on whether decryption of these messages succeeded, to eventually figure out and extract the victim’s private key.
To avoid this type of attack in the future, developers should identify sensitive data and encrypt them, even if stored on a hard drive. There should also be an effort to ensure the data cannot be overwritten by overwriting sensitive memory locations straight after the data is no longer needed in memory.
In regards to this specific vulnerability, it is suggested to upgrade openpgp to version 4.3.0 or above.
That is it from us…for now! Make sure to spread the word on these Javascript vulnerabilities in order to help protect your apps or the apps you develop. Read also our post about javascript vulnerabilities and remote code execution.
As you all know, open-source vulnerabilities are discovered daily, so you can expect us to be back with new vulnerabilities very soon!
Knowing is half the battle. The other half is doing. Let Meterian help your dev team stay in the know and on top of the latest updates to secure your apps continuously. Sign up here to download the Meterian client today. You’ll get an instant analysis of your first project for free. See the risks immediately and know which components to remove or upgrade to secure your app.
