CVE-2026-32604 and CVE-2026-32613 are both 10.0 severity vulnerabilities in Spinnaker, which allow attackers to execute arbitrary code and access credentials for production cloud environments and source control.

They give attackers a natural path to move from a compromised workstation to production, even when developers themselves don't have direct access.

Our blog post contains a comprehensive technical breakdown and working POCs.

Perforce is source control software used in games, entertainment, and a few engineering sectors. It's particularly useful when large binary assets need to be stored alongside source code. It handles binary assets much better than Git, IMO. However, its one weakness is its terrible security defaults. You will die a bit inside when you see the out-of-the-box behaviour: "Don't have an account? Let me make one for you!" and "Oh, you didn't know by default there is a hidden, read-only 'remote' user that allows read access to everything? Oops!"

I scanned 6,122 public Perforce servers last year. 72% were exposing source code, 21% had passwordless accounts, and 4% had unprotected superusers (which allow RCE). The vendor patched the largest issue, but a significant portion are still vulnerable.

Full write-up and methodology: https://morganrobertson.net/p4wned/

Tools repo, including Nuclei templates to scan your infra: https://github.com/flyingllama87/p4wned

Hardening is a pain, but here it is summed up: p4 configure set security=4 # disables the built-in 'remote' user + strong auth p4 configure set dm.user.noautocreate=2 # kills auto-signup p4 configure set dm.user.setinitialpasswd=0 # users cannot self-set first password p4 configure set dm.user.resetpassword=1 # force password reset flow p4 configure set dm.info.hide=1 # hide server license, internal IP, root path p4 configure set run.users.authorize=1 # user listing requires auth p4 configure set dm.user.hideinvalid=1 # no hints on bad login p4 configure set dm.keys.hide=2 # hide stored key/value pairs from non-admins p4 configure set server.rolechecks=1 # prevent P4AUTH misuse

Happy to answer any questions on the research!

[ Removed by Reddit on account of violating the content policy. ]

We analysed almost 100 UK charity websites and found that ~1 in 6 are running vulnerable JavaScript dependencies.

What stood out more though:

- Some vulnerabilities were 10+ years old, including high and critical ratings

- Same jQuery CVE (2015-9251) appearing across multiple organisations

We’ve now seen similar patterns in the HE/FE and also hospitality sectors as well.

Are we right in thinking that this feels like a visibility problem alongside budget issues more than anything else?

How are you tracking dependencies effectively in your organisations?

Full write-up if useful: https://cybaa.io/blog/2026-04-20/uk-health-charity-website-security-2026