Last Week in AppSec for 02. December 2025

The AppSec community had a busy week: last week in AppSec included a resurgence of the Shai-Hulud NPM worm, several GitLab self-hosted vulnerabilities to patch, a hard-coded key in the popular Apache Syncope identity system, and struggles with memory safety in libxml2 and libxslt.

Checkmarx Zero also published new research on emerging AI security risks; if you missed the announcement, it’s worth a read now.

• September brought us the first documented self-replicating NPM worm: Shai-Hulud; and last week, a modified and more-aggressive version dubbed “Shai-Hulud Second Coming” reared its head.
  
• The node-forge toolkit for JavaScript, which has been widely adopted as a provider for various encryption and digital signature purposes, has a vulnerability in versions through 1.3.1 that can lead to bypassing signature checks (CVE-2025-12816, CVSSv3 8.6). Update to nodeforge@1.3.2 or newer promptly if impacted.
  
• The open-source identity management and provisioning system Apache Syncope uses a default, hard-coded AES key to protect user passwords when administrators select “AES password encryption” for the storage method. This allows attackers who manage to get a copy of the encrypted password database to use this publicly-available key to decrypt every password stored. Syncope 2.1.0–2.1.14, 3.0.0–3.0.14, and 4.0.0–4.0.2 are affected, with fixes in 3.0.15 and 4.0.3, and a backported fix for 2.1.x available.
  
• A recent Ubuntu advisory brought new attention to older vulnerabilities in the libraries libxml2 and libxslt, which underly many applications with XML parsing or generation capabilities, including the GNOME desktop environment and Python’s popular lxml package. In April and July, several CVEs (CVE-2025-32414, CVE-2025-32415, CVE-2025-49794, plus libxslt CVE-2025-7425) were published related to memory-safety issues that can lead to crashes and other vulnerable behaviors in consuming applications.
  
• GitLab’s Community Edition and Enterprise Edition patch notes detail several significant vulnerabilities patched in GitLab 18.6.1, 18.5.3, and 18.4.5. The issues include a registration issue that can result in authentication bypass across organization and group boundaries.

Shai-Hulud’s Second Coming (Shai-Hulud 2.0)

September brought us the first documented self-replicating NPM worm: Shai-Hulud; and last week, a modified and more-aggressive version dubbed “Shai-Hulud Second Coming” reared its head.

This more-aggressive variant tried, with significant success, to bypass the controls that eventaually stopped the first worm. And it contained a surprise “punishment”: deleting a users’ files if the worm was unable to successfully steal GitHub or NPM credentials.

Fortunately, organization-level controls against the first iteration — such as adopting scoped tokens for NPM access, implementing proactive malicious package defenses, and using package manager proxies to centrally enforce supply chain policies — seem to have paid off. Despite the more aggressive nature, there was not a significantly higher number of NPM packages affected and the infestation was much more rapidly contained.

CVE-2025-12816: JavaScript cryptography toolkit “node-forge” signature validation bypass

The node-forge toolkit for JavaScript, which has been widely adopted as a provider for various encryption and digital signature purposes, has a vulnerability in versions through 1.3.1 that can lead to bypassing signature checks (CVE-2025-12816, CVSSv3 8.6). Update to nodeforge@1.3.2 or newer promptly if impacted.

This flaw originates in the asn1.js system’s asn1.validate() function, which is responsible for validating the structure of ASN.1 data blocks commonly used to represent various data structures involved in cryptographic signatures; it’s used in X.509 certificates, PKCS data, etc. In this implementation of the validator, malicious ASN.1 data blocks can desync its state, which can lead to invalid signatures being reported as valid in some cases.

If you use node-forge for any certificate-related functionality, especially signature verification, it’s critical to update to at least version 1.3.2 as soon as possible.

See the CMU CERT advisory for additional details.

CVE-2025-65998: Apache Syncope has hard-coded key for password storage

The open-source identity management and provisioning system Apache Syncope uses a default, hard-coded AES key to protect user passwords when administrators select “AES password encryption” for the storage method. This allows attackers who manage to get a copy of the encrypted password database to use this publicly-available key to decrypt every password stored. Syncope 2.1.0–2.1.14, 3.0.0–3.0.14, and 4.0.0–4.0.2 are affected, with fixes in 3.0.15 and 4.0.3, and a backported fix for 2.1.x available.

Fortunately, not everyone is impacted. AES encryption is not the default storage method. If administrators used something other than AES encryption, including the default hash-based option, then the risk is mitigated. Run the below on servers hosting syncope to determine if you have a vulnerable version, then check the configuration to see if AES is enabled.

Unfortunately though, if you are impacted, you must assume all passwords stored in Syncope have been compromised. That means you can’t just patch, you must:

1. Upgrade to a patched version (3.0.15 or 4.0.3) or apply the back ported 2.1.x patch
2. Rotate the encryption keys and re-encrypt the stored passwords
3. Force password resets for all users, both on Syncope itself, and on the systems that Syncope uses stored passwords to log into

Don’t forget to review logs for suspicious login activity.

Multiple CVEs in XML and XSLT parsing libraries

The libraries libxml2 and libxslt are ubiquitous and underly many applications with XML parsing or generation capabilities, including the GNOME desktop environment and Python’s popular lxml package. In April and July, several CVEs (CVE-2025-32414, CVE-2025-32415, CVE-2025-49794, plus libxslt CVE-2025-7425) were published related to memory-safety issues that can lead to crashes and other vulnerable behaviors in consuming applications. These popped back into focus this week due to a new Ubuntu security notice on the topic. Because this library is usually a transitive dependency, you must update your direct dependencies as needed to ensure the proper libxml2, lxml, python-libxml2, libxslt, etc. are available; don’t forget to check your containers!

If libxml2 is installed in your Linux host or container, you should be able to identify the version with a simple script like

#!/bin/bash
set -e
ver=$(xml2-config --version 2>/dev/null)
echo "libxml2 version: $ver  (vulnerable if < 2.13.8 or 2.14.0–2.14.1)"

Your package manager can also enumerate installed packages. On Ubuntu, for example, you can run:

dpkg -l libxml2

Upgrading these packages is easy enough, but can often break consuming applications; have a test and rollback plan ready.

GitLab updates to address multiple vulnerabilties

GitLab’s Community Edition and Enterprise Edition patch notes detail several significant vulnerabilities patched in GitLab 18.6.1, 18.5.3, and 18.4.5.

• CVE-2025-12653: GitLab CE/EE 18.3–18.4.4, 18.5.0–18.5.2, 18.6.0.
• CVE-2025-7449: GitLab CE/EE 8.3–18.4.4, 18.5.0–18.5.2, 18.6.0.
• CVE-2025-6195: GitLab EE 13.7–18.4.4, 18.5.0–18.5.2, 18.6.0.
• CVE-2025-13611: GitLab CE/EE 13.12–18.4.4, 18.5.0–18.5.2, 18.6.0

CVE-2025-12653 (CVSS=6.5) allows attackers to bypass authentication checks by spoofing certain request headers, allowing them to register for accounts within existing organizations. This degrades protections for group/namespace membership and allows attackers to gain a foothold that escalates into projects and CI access.

CVE-2025-7449 (CVSS=6.5) is a resource exhaustion bug that allows attackers to send unbounded data requests that GitLab must then allocate resources to process. This leads to costs and DoS opportunities.

CVE-2025-6195 (CVSS=4.3) and CVE-2025-13611 (CVSS=2.0) are information disclosure issues. 6195 allows access to security reports the user shouldn’t have access to, and is based in a Markdown rendering bug. 13611 is the result of logging sensitive information that can show up in Terraform and similar logs.

If you self-host GitLab, make sure to check your version and edition and patch accordingly.