Post-Quantum Cryptography, OpenSSH, & s1ngularity supply chain attack

Hello ! Jordan_Zebor​ is your editor this time for the F5 SIRT This Week in Security, covering Post-Quantum Crypto and an NPM supply chain attack.

Post-Quantum Cryptography Blog Series

At F5, we are publishing a forward‑looking series of blog posts which help security and IT leaders anticipate tomorrow’s risks and capitalize on emerging tech. Think of it as a field guide to future threats—and how to stay resilient as they arrive. We are about halfway through the series. Here are some of the highlights from my point of view.

The quantum threat is a now problem: harvest-now-decrypt-later makes today’s encrypted data future loot. Mosca’s inequality means if data longevity plus migration time exceeds time to quantum computers. You’re at risk—regardless of the exact Q-Day.

Standards and deadlines are set but readiness lags: NIST finalized ML-KEM (FIPS 203), ML-DSA (FIPS 204), SLH-DSA (FIPS 205) with HQC slated for 2027; U.S. agencies must migrate by 2030 and NSS by 2035, yet sector adoption is low and client support uneven—so build crypto-agility for multiple future pivots.

Act pragmatically now: deploy hybrid TLS with PQC KEMs at the edge, inventory your crypto,  prioritize long-lived data, modernize PKI (hybrid/dual-signature, quantum-safe roots), engage vendors, dig into performance, HSM capacity, and any legacy crypto constraints.

For more information, visit one or more of the F5 Blog Series on Post-Quantum Cryptography

• Weighing in on the Post-Quantum Cryptography Hype
• Setting the Stage: Why Does PQC Matter?
• Understanding PQC Standards and Timelines
• Apps, networks, and legacy systems in the quantum crosshairs: A CISO's POV

OpenSSH makes post-quantum KEX the default

OpenSSH has supported post-quantum key exchange for years to mitigate “store now, decrypt later” risks, where attackers record today’s encrypted SSH traffic and decrypt it once quantum computers arrive. Post-quantum Key Exchange (KEX) became the default in OpenSSH 9.0 with sntrup761x25519-sha512; a second option, mlkem768x25519-sha256, was added in 9.9 and made the default in 10.0 (April 2025). Starting in OpenSSH 10.1, users will start to see a warning when a connection doesn’t use a post-quantum KEX (the warning can be silenced with WarnWeakCrypto config option). The expectation that cryptographically relevant quantum computers could appear within 5–20 years (often pegged to the mid‑2030s) motivated the push. Breaking key agreements would expose entire SSH sessions retrospectively. If you get the warning, your server isn’t offering the two PQ KEX algorithms being standardized for SSH (mlkem768x25519-sha256 or sntrup761x25519-sha512). 

The recommended fix is to upgrade the server: OpenSSH 9.0+ supports sntrup…, and 9.9+ supports mlkem…; also verify KexAlgorithms hasn’t disabled them. Quantum also threatens signature algorithms (RSA, ECDSA) but there’s no retroactive decryption risk for past traffic. The priority is to retire classical signing keys before quantum arrives, with PQ signatures to be added in future OpenSSH releases. To hedge against unforeseen weaknesses, OpenSSH uses hybrid schemes (PQ + classical x25519). This ensures security is at least as strong as the prior classical default even if the PQ component were broken.

Reference: https://www.openssh.com/pq.html

The s1ngularity supply chain attack

On August 26, 2025, attackers slipped malicious versions of the popular Nx build system onto the Node Package Manager (npm). Installing these packages ran hidden code that stole developer secrets—like GitHub and npm tokens, SSH keys, .env files, and even crypto wallets—and pushed them into new public repositories created inside the victims’ own GitHub accounts. GitHub disabled those repos about 8 hours later, but not before data could be copied. A second wave then used the stolen GitHub tokens to flip thousands of private repos to public, impacting 400+ users and organizations and more than 5,500 repositories.

Under the hood, a post-install script (telemetry.js) executed on Linux and macOS, scanned for sensitive files, abused installed AI command‑line tools with unsafe flags to aid reconnaissance, and exfiltrated double/triple‑base64 blobs to repos named “s1ngularity-repository” variants. The root cause was traced back to a vulnerable GitHub Actions workflow that ran with elevated permissions and allowed command injection via unsanitized pull request titles. The malware also tried to break machines by adding a forced shutdown command to shell startup files. What to do: remove the compromised Nx versions and update to clean releases, clear node_modules and npm cache, strip the shutdown lines from shell rc files, delete temporary inventory files, audit GitHub for rogue activity, and rotate all tokens, keys, and API secrets. Treat any exposed data as public and move any affected cryptocurrency to new wallets. 

Reference: https://www.wiz.io/blog/s1ngularity-supply-chain-attack