We are deeply numbed, shocked and saddened today by the sudden and tragic loss of our fellow technician, coworker, compatriot […]
We are deeply numbed, shocked and saddened today by the sudden and tragic loss of our fellow technician, coworker, compatriot […]
Overview
A major npm supply chain compromise was disclosed by the software supply chain security company Socket on September 15, 2025. At the time of writing, over 500 packages have been affected, and the number continues to grow. The attack involves a self-propagating malware variant dubbed Shai-Hulud, which spreads via credential theft and automated package publishing. The campaign escalated rapidly, including compromise of packages published by CrowdStrike.
This notice aims to raise awareness about growing risks in software development and packaging practices within the npm ecosystem that can lead to large-scale compromises. The incident highlights ongoing exploitation of known attack vectors, including credential theft, package impersonation, and automated propagation, all of which undermine the integrity of widely used package ecosystems like npm.
Description
npm is the default package manager for Node.js. It provides a global registry and command-line interface that helps developers install, manage, and share JavaScript packages and dependencies. It simplifies the integration of third-party code through the use of the package.json and package-lock.json files, which ensure dependency consistency and reproducibility.
The compromise likely began with a credential harvesting campaign, where a postinstall script led to the execution of a malicious bundle.js file. postinstall scripts are an npm feature that allow code execution following package installation. The bundle.js script scanned the target environment for exposed secrets in code and configuration files. The bundle.js file downloaded and used TruffleHog, typically used for legitimate secret scanning, to harvest credentials stored as environment variables or secrets used by continuous integration and continuous delivery (CI/CD) platforms such as GitHub Actions, GitLab CI, Jenkins, and others. The malware self-propagated using the stolen credentials to publish itself to other repositories and package registries, effectively turning compromised environments into new infection vectors.
A key mechanism of propagation was the automatic “trojanization” of CI/CD tools, a known attack vector with wide-reaching implications across ecosystems. GitHub Actions was one such capability that was abused, previously seen in attacks like the Nx package compromise in August of 2025. Another known contributor to the attack was the abuse of the postinstall script capability in npm. This technique has been exploited in previous incidents, such as the event-stream attack in 2018. These vulnerable software development and design methods in npm have been duly abused in this combined attack.
Impact
At the time of publication, over 500 packages have been confirmed to be compromised by the Shai-Hulud malware. Socket is maintaining a live list of affected packages on their website. Organizations using CrowdStrike products should also inspect their npm package dependencies, as the npm account used to manage and publish packages for CrowdStrike was allegedly compromised.
Solution
GitHub has released a public advisory detailing additional security changes being made to their package systems. CISA has also released a security advisory.
For npm Users
Audit and replace compromised packages: Remove any affected package versions and replace them with known safe versions.
Lock dependencies: Use package-lock.json or npm i –package-lock-only to lock resolved dependency versions without executing install scripts, allowing safe auditing. For packages that will be redistributed, locally or otherwise, use npm shrinkwrap to lock all direct and transitive dependency versions for reproducible installs.
Use internal mirrors: Set up an internal npm registry using tools like Verdaccio or Artifactory, and centrally approve packages before allowing internal use.
Disable postinstall scripts: Use npm install –ignore-scripts where feasible to prevent malicious code execution during package installation.
For npm Developers
Rotate all exposed credentials: Immediately revoke and rotate any CI/CD-related tokens or secrets (GitHub, GitLab, Jenkins, etc.) that may have been exposed.
Enforce least privilege: Use scoped tokens with minimal permissions, and isolate build environments to ensure untrusted code never has access to publishing credentials, especially when using GitHub Actions or similar CI/CD platforms.
Acknowledgements
This document was written by Christopher Cullen.
Overview
Lectora Desktop versions 21.0–21.3 and Lectora Online versions 7.1.6 and older contained a cross-site scripting (XSS) vulnerability in courses published with Seamless Play Publish (SPP) enabled and Web Accessibility disabled. The vulnerability was initially patched in Lectora Desktop version 21.4 (October 25, 2022), but users must republish existing courses to apply the patch. This important republishing instruction was missing from the Desktop edition release notes, but it was included in the release notes for the recently patched Lectora Online (July 20, 2025). The CERT® Coordination Center is publishing this vulnerability note to amplify awareness as the Lectora software user base includes high-profile clients such as government agencies and large enterprises.
Description
The Lectora platform is used to create and publish interactive e-learning courses by ELB Learning. Lectora Inspire and Lectora Publisher are Desktop versions of the e-learning software, and Lectora Online is a cloud-based version.
Affected Versions
Lectora Inspire and Lectora Publisher desktop editions versions 21.0–21.3
Lectora Online versions 7.1.6 and older
Impact
Content published with Seamless Play Publish (SPP) enabled and Web Accessibility settings disabled in the affected versions can allow JavaScript injection via crafted URL parameters. Exploitation under this scenario could result in client-side script execution (e.g., alert or redirect), which poses a risk of session hijacking or user redirection.
Solution
The vulnerability is patched in Lectora Desktop (Publisher and Inspire version 21.4, released October 25, 2022) and Lectora Online (version 7.1.7, deployed July 20, 2025). To fully implement the solution:
For Lectora Desktop customers: Please download the version 21.4 patch or a later update from portal.elblearning.com. You must then republish any courses that were created using older software versions.
For Lectora Online customers: The update to version 7.1.7 was automatically applied on July 20, 2025. You must republish any courses that were created using older software versions.
Acknowledgements
Thanks to the reporter Mohammad Jassim for reporting this vulnerability. This document was written by Laurie Tyzenhaus.
Overview
LangChainGo, the Go implementation of LangChain, a large language model (LLM) application building framework, has been discovered to contain an arbitrary file read vulnerability. The vulnerability, tracked as CVE-2025-9556, allows for arbitrary file read through the Gonja template engine with Jinja2 syntax. Attackers can exploit this by injecting malicious prompt content to access sensitive files, leading to a server-side template injection (SSTI) attack.
Description
LangChainGo is the Go Programming Language port/fork of LangChain, an open-source orchestration framework for the development of applications that leverage LLMs. LangChainGo uses Gonja for syntax parsing and creating dynamic and reusable prompt templates. Gonja is the Go implementation of Jinja2, a templating engine. Gonja is largely compatable with the the original Python Jinja2 implementation, and supports Jinja2 syntax.
As Gonja supports Jinja2 syntax, an attacker could leverage directives such as % include %, % from %, or % extends % for malicious purposes within LangChainGo. While these directives were meant to be used for building reusable templates, they can also allow an external file to be pulled and read from the server’s filesystem. An attacker could use this to inject malicious template code containing advanced templating directives to read sensitive files such as /etc/password. This results in a server-side template injection vulnerability that can expose sensitive information. This vulnerability is tracked as CVE-2025-9556.
Impact
This vulnerability compromises the confidentiality of the system by enabling arbitrary file read on a server running LangChainGo. By injecting malicious template syntax, an attacker could access sensitive information stored on the victim device. This information can lead to further comprise of the system. In LLM-based chatbot environments that use LangChainGo, attackers would only need access to the prompt to maliciously craft and exploit the prompt.
Solution
The maintainer of LangChainGo has released with new security features to prevent template injection. A new RenderTemplateFS function has been added, which supports secure file template referencing, on top of blocking filesystem access by default. Users of LangChainGo should update to the latest version of the software in order to be protected.
Acknowledgements
Thanks to the reporter, bestlzk. This document was written by Ayushi Kriplani and Christopher Cullen.
Overview
Two local security vulnerabilities have been identified in Sunshine for Windows, version v2025.122.141614 (and likely prior versions). These issues could allow attackers to execute arbitrary code and escalate privileges on affected systems.
Description
Sunshine is a self-hosted game stream host for Moonlight.
CVE-2025-10198 Unquoted Service Path (CWE-428)
Sunshine for Windows installs a service with an unquoted service path. This allows an attacker with local access to place a malicious executable in a directory within the service path (before the legitimate binary), which could then be executed with elevated privileges during system startup or service restart.
CVE-2025-10199 DLL Search-Order Hijacking (CWE-427)
Sunshine for Windows does not properly control the search path for required DLLs. This allows an attacker to place a malicious DLL in a user-writable directory that is included in the PATH environment variable. When the application loads, it may inadvertently load the malicious DLL, resulting in arbitrary code execution.
Impact
CVE-2025-10198 Attackers with local access can escalate privileges to SYSTEM, resulting in full compromise of the affected machine.
CVE-2025-10199 Attackers can execute malicious code in the context of the user running the application.
Solution
Apply an update from the Sunshine project once available.
As mitigation, until a patch is released:
Ensure user-writable directories are not included in the PATH environment variable.
Quote all service paths in Windows service configurations.
Restrict permissions on service-related directories to prevent unauthorized file placement.
Acknowledgements
Thanks to the reporter, Pundhapat Sichamnong. This document was written by Timur Snoke.
Overview
The Amp’ed RF BT-AP 111 Bluetooth Access Point exposes an HTTP-based administrative interface without authentication controls. This allows an unauthenticated remote attacker to gain full administrative access to the device.
Description
The Amp’ed RF BT-AP 111 is a Bluetooth-to-Ethernet bridge that can function as an access point or a Bluetooth gateway. According to the vendor’s website, the device supports Universal Plug and Play (UPnP) on the Ethernet side and acts as a UART Serial device to support up to seven simultaneous Bluetooth connections.
The BT-AP 111 provides a web-based administrative interface over HTTP. However, this interface does not implement any authentication mechanism. As a result, any user with network access to the device’s HTTP port can view and modify the administrative interface. An attacker with such access can alter Bluetooth configurations, network parameters, and other security-related settings.
According to NIST guidance, authentication is an expected baseline security control even for near-field or Bluetooth devices. The NIST Guide to Bluetooth Security (SP 800-121 Rev. 2), defines security levels that require at least authentication (Service Level 2) and preferably authentication and authorization (Service Level 1). More broadly, NIST SP 800-124 Rev. 1 emphasizes that devices should enforce authentication before granting access to configuration or administrative resources. The absence of authentication on the BT-AP 111 administrative web interface is therefore inconsistent with established best practices.
Impact
An attacker with network access (local or remote) to the web interface can gain full administrative control of the device and modify any settings exposed through the interface.
Solution
At this time, CERT/CC has not received a response from the vendor regarding this vulnerability. Since the device cannot be secured with authentication or any access controls, it is recommended that any deployments be restricted to isolated networks that are inaccessible to untrusted users.
Acknowledgements
Thanks to the reporter, Souvik Kandar. This document was written by Timur Snoke.
Overview
Hiawatha is an open-source web server that supports Windows, MacOS X and a variety of Linux distributions. Hiawatha was focused on performance and is used in place of larger, more complex web servers. The fetch_request is vulnerable due to improper handling of HTTP headers regarding content length and transfer encoding. Tomahawk is a component of the Hiawatha web server which is vulnerable to authentication timing attack due to usage of ‘strcmp’ and may allow a local attacker to access the management client. The double free in the XSLT show_index function is a memory handling problem. The developer acknowledges the vulnerabilities and has tested the update to ensure all three are mitigated or remediated. Hiawatha is no longer actively supported by the developer, but the developer acknowledges the vulnerabilities and has included mitigations and remediations to all three vulnerabilities in the next release.
Description
CVE-2025-57783 A request smuggling vulnerability caused by improper header parsing has been identified in the fetch_request function of Hiawatha web server versions 8.5 through 11.7. This vulnerability allows an unauthenticated attacker to smuggle requests and access restricted resources managed by the server.
CVE-2025-57784 An authentication timing attack has been identified in the Tomahawk component of Hiawatha web server versions 8.5 through 11.7, which occurs due to the use of strcmp in the handle_admin function. This vulnerability allows a local attacker to access the management client.
CVE-2025-57785 A double free in the XSLT show_index function has been identified in Hiawatha web server version 10.8.2 through 11.7. This vulnerability allows an unauthenticated attacker to corrupt data, which may lead to arbitrary code execution.
Impact
Exploiting the request smuggling vulnerability may result in attackers bypassing authentication, hijack user sessions or inject malicious payloads into requests.
Exploiting the timing ‘strcmp’ function in the handle_admin function may result in password attempts to measure the time for each attempt, then assume the password is known by the longest attempt which would match more characters. This vulnerability may be time consuming to exploit.
Exploiting the double free error is when a program tries to free memory in the same location more than once. In a web server the XSLT show_index function may originate from an error in memory management during the execution of the XSLT which may result in corrupt data leading to the execution of arbitrary code.
Solution
Install updated version when distributed by Hiawatha.
Acknowledgements
Thanks to the reporter Ali Norouzi of Keysight.This document was written by Laurie Tyzenhaus.
Overview
Workhorse Software Services, Inc municipal accounting software prior to version 1.9.4.48019 contains design flaws that could allow unauthorized access to sensitive data and facilitate data exfiltration. Specifically, database connection information is stored in plaintext alongside the application executable, and the software allows unauthenticated users to create unencrypted database backups from the login screen.
Description
Two primary issues exist in Workhorse’s design:
Plaintext Database Connection String
CVE-2025-9037 The software stores the SQL Server connection string in a plaintext configuration file located alongside the executable. In typical deployments, this directory is on a shared network folder hosted by the same server running the SQL database. If SQL authentication is used, credentials in this file could be recovered by anyone with read access to the directory.
Unauthenticated Database Backup Functionality
CVE-2025-9040 The application’s “File” menu, accessible even from the login screen, provides a database backup feature that executes an MS SQL Server Express backup and allows saving the resulting .bak file inside an unencrypted ZIP archive. This backup can be restored to any SQL Server instance without requiring a password.
An attacker with physical access to a workstation, malware capable of reading network files, or via social engineering could exfiltrate full database backups without authentication.
Impact
An attacker could obtain the complete database, potentially exposing sensitive personally identifiable information (PII) such as Social Security numbers, full municipal financial records, and other confidential data. Possession of a database backup could also enable data tampering, potentially undermining audit trails and compromising the integrity of municipal financial operations.
Solution
The CERT/CC recommends updating the software to version 1.9.4.48019 as soon as possible.
Other potential mitigations include:
* Restricting access to the application directory via NTFS permissions
* Enabling SQL Server encryption and Windows Authentication
* Disabling the backup feature at the vendor or configuration level
* Using network segmentation and firewall rules to limit database access
Acknowledgements
This issue was reported during a security audit and new server installation by James Harrold, Sparrow IT Solutions. This document was written by Timur Snoke.
Overview
System Management Mode (SMM) memory corruption vulnerabilities have been identified in UEFI modules present in AMI Aptio UEFI firmware. An attacker could exploit this vulnerability to elevate privileges and execute arbitrary code in the highly privileged SMM environment. Users should apply UEFI firmware updates provided by their supply-chain-supported vendors to address these issues.
Description
The Unified Extensible Firmware Interface (UEFI) specification defines an interface between an operating system (OS) and platform firmware. The UEFI specification defines mechanisms that allow firmware code to execute in System Management Mode (SMM), a highly privileged CPU mode intended for low-level system operations and direct hardware access. SMM operations are executed within a CPU protected memory region called System Management RAM (SMRAM). This environment is often referred to as “ring -2” because it operates at a deeper privilege level than the OS kernel (ring 0) and hypervisor (ring -1).
A vulnerability has been identified in certain firmware modules of AMI APTIOV related to improper pointer validation. Specifically, the code fails to adequately validate pointer values to prevent overlap with SMRAM. This allows memory references to be redirected into SMRAM, potentially enabling unauthorized code execution within SMM. An attacker exploiting this flaw could corrupt memory and overwrite sensitive SMRAM data, including firmware components that may later be written to PCI flash memory—establishing persistent control over the device.
Impact
Successful exploitation of this vulnerability may allow execution of code within System Management Mode (SMM), a highly privileged environment in firmware. This could bypass certain firmware-level protections, such as those protecting the SPI flash memory, and enable persistent modifications to the firmware that operate independently of the OS.
Solution
Install the latest UEFI firmware updates provided by your PC vendor. Refer to the Vendor Information section below and AMI’s security advisory. As these vulnerabilities may affect firmware distributed through the supply chain, multiple PC OEMs may be impacted. Continue monitoring the Vendor Information section for updates relevant to your device.
Acknowledgements
Thanks to Binarly REsearch team for the responsible disclosure of this vulnerability to CERT/CC. Thanks also to AMI for their collaboration and timely response. This document was written by Ben Koo.
Overview
A vulnerability has been discovered within many HTTP/2 implementations allowing for denial of service (DoS) attacks through HTTP/2 control frames. This vulnerability is colloquially known as “MadeYouReset” and is tracked as CVE-2025-8671. Some vendors have assigned a specific CVE to their products to describe the vulnerability, such as CVE-2025-48989, which is used to identify Apache Tomcat products affected by the vulnerability. MadeYouReset exploits a mismatch caused by stream resets between HTTP/2 specifications and the internal architectures of many real-world web servers. This results in resource exhaustion, and a threat actor can leverage this vulnerability to perform a distributed denial of service attack (DDoS). This vulnerability is similar to CVE-2023-44487, colloquially known as “Rapid Reset.” Multiple vendors have issued patches or responses to the vulnerability, and readers should review the statements provided by vendors at the end of this Vulnerability Note and patch as appropriate.
Description
A mismatch caused by client-triggered server-sent stream resets between HTTP/2 specifications and the internal architectures of some HTTP/2 implementations may result in excessive server resource consumption leading to denial-of-service (DoS). This vulnerability is tracked as CVE-2025-8671 and is known colloquially as “MadeYouReset.” This vulnerability is similar to CVE-2023-44487, colloquially known as “Rapid Reset”, which abused client-sent stream resets. HTTP/2 introduced stream cancellation – the ability of both client and server to immediately close a stream at any time. However, after a stream is canceled, many implementations keep processing the request, compute the response, but don’t send it back to the client. This creates a mismatch between the amount of active streams from the HTTP/2 point of view, and the actual active HTTP requests the backend server is processing.
By opening streams and then rapidly triggering the server to reset them using malformed frames or flow control errors, an attacker can exploit a discrepancy created between HTTP/2 streams accounting and the servers active HTTP requests. Streams reset by the server are considered closed, even though backend processing continues. This allows a client to cause the server to handle an unbounded number of concurrent HTTP/2 requests on a single connection.
The flaw largely stems from many implementations of the HTTP/2 protocol equating resetting streams to closing them; however, in practice, the server will still process them. An attacker can exploit this to continually send reset requests, where the protocol is considering these reset streams as closed, but the server will still be processing them, causing a DoS.
HTTP/2 does support a parameter called SETTINGS_MAX_CONCURRENT_STREAMS, which defines a set of currently active streams per session. In theory, this setting would prevent an attacker from overloading the target server, as they would max out the concurrent stream counter for their specific malicious session. In practice, when a stream is reset by the attacker, the protocol considers it no longer active and no longer accounts for it within this counter.
Impact
The main impact of this vulnerability is its potential usage in DDoS attacks. Threat actors exploiting the vulnerability will likely be able to force targets offline or heavily limit connection possibilities for clients by making the server process an extremely high number of concurrent requests. Victims will have to address either high CPU overload or memory exhaustion depending on their implementation of HTTP/2.
Solution
Various vendors have provided patches and statements to address the vulnerability. Please review their statements below. CERT/CC recommends that vendors who use HTTP/2 in their products review their implementation and limit the number/rate of RST_STREAMs sent from the server. Additionally, please review the supplemental materials provided by the reporters, which include additional mitigations and other potential solutions here: https://galbarnahum.com/made-you-reset
Acknowledgements
Thanks to the reporters, Gal Bar Nahum, Anat Bremler-Barr, and Yaniv Harel of Tel Aviv University. This document was written by Christopher Cullen.