The security tool you install to protect a server can become the way in. The cPGuard breach is the textbook case. What happened On Nov 2, an attacker used compromised credentials to get into the vendor's update system and pushed a malicious script through versions 5.88.12 to 5.88.19. It grabbed password hashes, the root database config and root SSH files. Only servers running cPGuard are affected. It's sold for cPanel, Plesk and DirectAdmin, so if you or a client host a site on one of those panels, it's worth checking. Vendor notice: https://opsshield.com/notice/cpguard-update-channel-compromise.html The 10-minute check 1. Find out if cPGuard is on the box. Look in your hosting panel's installed plugins, or ask your host or web person directly. If it isn't installed, you're not affected by this one. 2. Check the version history. Did any of your servers install 5.88.12 to 5.88.19? That's the question to get answered today. 3. Update to 5.88.25 or later. That's the fix, but it's only step one. 4. Rotate everything the script could reach. Change server passwords, database logins and SSH keys. Copied credentials may still work after the cleanup, so updating alone isn't enough. 5. Write down who owns vendor updates. For every auto-updating tool on your servers, know who gets the vendor's security notices and who would act on them. Why this keeps happening I've seen this pattern from the inside: attackers go after security vendors because their access is trusted everywhere. A tool that updates itself with root access is a tool you're trusting with the keys. My read after 30 years in corporate America, the last 7 at AWS: treat every auto-updating security tool like an admin account. Drop a reply: who on your team would even know if a vendor's update went bad? — Keith

Most of us worry about what our AI tool says. In October, the real risk was the keys stored behind it. What happened Wiz counted at least 9 AI developer platforms that disclosed incidents last month, from Fireworks AI on Oct 6 to Northflank on Oct 30. The common thread: attackers going after stored secrets, especially AI API keys, which then get resold cheap. Northflank told customers to assume every stored environment variable was decrypted and to rotate all of them. Wiz also tracked two stolen enterprise AWS Bedrock keys. One made about 800K calls in 30 hours, the other about 1.7M in 13. Wiz estimates more than $100K at list price for the two. If you build anything that runs on an AI key (a website chatbot, an after-hours agent, an OpenClaw or Hermes setup), this is for you. What I saw at AWS At AWS, we scanned public code repos for exposed keys and warned customers when we found theirs. The biggest issue was a .env file, where developers keep keys, committed right into the repo. The lockdown checklist 1. Check your .gitignore. Make sure .env is in it before your next commit. If a .env file was ever committed, treat those keys as exposed and rotate them, since deleting the file later doesn't remove it from history. 2. Move keys into a managed key store. Use your cloud's secrets manager so keys never sit in a file at all. Your app reads them at runtime. 3. Set a spending cap. The bill lands on whoever owns the key. Set budget limits and alerts on every AI provider account you use. 4. Limit where a key can run. A key allowed to run anywhere is harder to throttle. Wiz found the key limited to US regions ran into regional quotas, which throttled hundreds of thousands of calls. On the key allowed global routing, only about 6% were throttled. 5. Rotate on a schedule. Pick a cadence, put it on your calendar, and rotate right away if a vendor discloses an incident. If a vendor holds your key Ask them one question: "Where is our AI key stored, does it have a spending cap, and when did you last rotate it?"