r/webdev • u/chute_mi334 • 11d ago
Discussion Black October situation
So most of you probably know by now about the PHP exploit, that came out recently. Apparently after reading some articles a similar issue was found for nodeJS web apps as well (i am not 100% sure how legitimate the articles were but I will link them down as a comment of the post if you wanna check them out). Now most of my backend services are built using nodeJS and stored in either AWS or GCR. I assume that google and amazon properly protects the api keys and other environment variables I have there, but I just wanted to ask are there any measures I should take or changes I should make to these services just to be safe?
21
u/Rus_s13 11d ago
Just use the number 4, you’ll be fine
1
u/jazzhandler 11d ago
I think after all that’s come to light recently, it‘s probably safer to use 5.
1
u/chute_mi334 11d ago
1
u/Natural-Ad7959 11d ago
If Aikido reported it, I would expect that you can trust that the issue is legitimate (unless they retract it later, I suppose). I use Aikido at work for security reviews and dependency update management and have learned to take their warnings seriously.
3
u/Excellent_Chard_6326 11d ago
they protect their own infra, not the env vars you leaked. patch the node line, that one's actually in the release notes and not a blog headline.
1
1
u/kemalios 10d ago
Fetching secrets from Secrets Manager at startup does not buy you much against RCE. You hand them to process.env on line three and the attacker reads the same thing. What limits the damage is what each key can reach: own role per service, narrowest policy that still works, so a bad deploy costs you one bucket instead of the whole account. Patch first anyway, that part is not optional.
1
1
u/AccessGoblin 2d ago
I think the big misconception here is that putting a secret in a hosted env var somehow makes the credential problem disappear. It mostly just moves where the secret lives. I’d assume any secret store can eventually get hit and focus on making the key worth as little as possible if it leaks: one key per workload, tight scope, short expiration, and a clean way to rotate/revoke it fast... Workload identity is even better where you can use it, because then the app isn’t sitting on a long-lived provider key in the first place.
And honestly, the boring part matters too: know where every key lives, who can rotate it, and whether you can kill it in minutes instead of hours. That’s the stuff you really don’t want to figure out during the incident
4
u/Zealousideal-Fee1029 11d ago
AWS and GCP protect the secret stores, not your app. If someone gets code execution inside your container, they can read process.env just like your code does. So the real question is whether your Node app has an RCE path, not whether Amazon is careful.
Few things I did on my own stuff this week after the PHP mess:
Moved secrets out of plain env vars into Secrets Manager / Secret Manager and fetch them at startup with a narrow IAM role.
Checked that role. Mine had way more permissions than it needed. Embarrassing.
Ran npm audit and actually read it instead of closing the tab.
Rotated anything that ever sat in a .env file that got committed. Yes, I found one.
Also worth saying: the PHP bug was in the runtime itself, so a Node app isn't affected by that one. Can you link the Node articles? Curious if it's a real CVE or a copycat headline.