Last Week in AppSec for 2. September 2025

Here are some news items our team found interesting over the past week, which you might have missed.

• Payload CMS SQLite adapter session management issues can lead to account takeover (CVE-2025-4644 and CVE-2025-4633). New accounts could inherit a reused JWT, enabling account takeover. Update Payload, @payloadcms/next, and @payloadcms/graphql to 3.44.0 or newer, invalidate all sessions, rotate JWT secrets, and review auth logs for odd sign-ins.
  
• Malicious Nx versions, including several items in the @nx namespace, were published to npm via compromised pipeline (no CVE yet issued). Malicious releases exfiltrated credentials and created repos on victim GitHub accounts. Check GitHub security logs for creation of repos anamed s1ngularity-repository. Also rotate tokens (GitHub, npm, CI), upgrade Nx Console to stop implicit installs, and pin deps with provenance.

Don’t miss Checkmarx Zero updates

Subscribe

Never Miss Checkmarx
Zero Research Updates. Subscribe today!

By submitting my information to Checkmarx, I hereby consent to the terms and conditions found in the Checkmarx Privacy Policy and to the processing of my personal data as described therein. By clicking submit above, you consent to allow Checkmarx to store and process the personal information submitted above to provide you the content requested.

Session fixation in Payload CMS When Using SQLite

Payload CMS SQLite adapter session management issues can lead to account takeover (CVE-2025-4644 and CVE-2025-4633). New accounts could inherit a reused JWT, enabling account takeover. Update Payload, @payloadcms/next, and @payloadcms/graphql to 3.44.0 or newer, invalidate all sessions, rotate JWT secrets, and review auth logs for odd sign-ins. CERT Polksa has a short summary of the report for both CVEs in one spot.

While these vulnerabilities are Medium severity, they’re an excellent case study in the difficulty developer and AppSec teams face when implementing basic security controls. The root cause for both vulnerabilities is a failure to invalidate sessions that are no longer valid (one when logging out, and one when deleting an account).

Failure to invalidate a session when logging out means that even after a user has logged out, their session token is still valid. This increases the window of time an attacker can use a session token they’ve managed to steal, lowering costs for the attacker. Fortunately for Payload’s users, the developers set a relatively short token lifetime (2 hours), which mitigates the risk significantly. Even so, it’s an important reminder: logging out should invalidate all related sessions.

And failure to invalidate sessions when deleting a user account — combined with insufficient randomness when generating session tokens — leads to takeovers of new accounts. Attackers can create a new account, which means they recieve a valid session token, then rapidly delete that account. The next new account (created by a legitimate user) has a chance of getting that same token issued to them; the attacker then already has a valid token they can use to access a new legitimate user’s data. Again, short session timeouts mitigate this risk significantly, but the lesson remains: invalidating sessions when they’re terminated by the user in anway is important.

Defense in depth is the savior in this story. Had the Payload team not decided on reasonably short token lifeimes, the window of attack — and therefore the risk to users — would be significantly higher.

Open-source packages for the Nx build system infected with malware

Malicious Nx versions, including several items in the @nx namespace, were published to npm via compromised pipeline (no CVE yet issued). Malicious releases exfiltrated credentials and created repos on victim GitHub accounts. Check GitHub security logs for creation of repos anamed s1ngularity-repository. Also rotate tokens (GitHub, npm, CI), upgrade Nx Console to stop implicit installs, and pin deps with provenance.

If you track security news, you probably didn’t miss this one last week; but it’s a big deal, and if you were impacted you should do more than just block the impacted versions and update everyone – it’s an opportunity to review how you secure your CI pipelines and developer workstations against malicious package content.

We recommend reviewing the full advisory, which contains an excellent write-up from the Nx team about how the issue was introduced, discovered, etc.. And it also contains a lot of detailed information about the nature of the exploit and how it was able to leak secrets despite seemlingly not having access.

It’s essential that security teams take a “DevSecOps” approach to this class of problems: this isn’t just an “Nx let a vulnerability through” issue, but a fundamental issue with the combination of rapid delivery pace and general shortcomings in tools, tactics, and processes for defenders to secure CI/CD environments. It’s a perfect opportunity for a DevSecOps shared-responsibility style analysis. What controls do you have in place? If you were impacted, did these controls stop secrets from leaking? Did they warn you? If you were not impacted, would you have caught or prevented this? If not, take some time to consider your strategy for keeping your CI/CD workloads safe, while preserving the rapid delivery advantages of your overall DevOps strategy.