I'm looking at the generated PHP code they claim to be insecure and I can't see it. The client_secret is defined inside the file as a constant, ok it's sloppy and could be better, but this is not a vulnerability.

They claim the extract line is insecure, but never explain why, and without showing the rest of the code (what is $requiredHeaders? If it's sanitized this is a non issue) you can't even tell if it's secure or not.

The variable names being wrong (the $PayPal- ones) is probably just a "mistake" the model made, but it's not a vulnerability either.

This article could be just "burglars are burgling in your neighborhood, install our burglar alarm" from crowdstrike just as well.

It's not surprising that guardrail triggers would degrade model performance. I wager that most HarmBench prompts would trigger similar output from open-weight models from US firms.

The link you cited postulates it is accidental.

Certainly? I don’t have time to read the whole thing but-

> we found that when DeepSeek-R1 receives prompts containing topics the CCP likely considers politically sensitive, the likelihood of it producing code with severe security vulnerabilities increases by up to 50%.

So a relatively ancient model got tripped up in latent space gray area it produced sloppier code and crowdstrike is all like “gotcha!” Sounds like the basic thesis? Not great support, more like FUD

Reminds me of the worms that won't hack you if the OS language is set to Russian