Apiiro scanned 104,185 public copies of .claude/settings.local.json on GitHub between Nov 1 and 3, 2026. 1,122 of them (1.1%) held at least one secret, 1,379 in total. Among them: 379 database passwords, 43 SSH logins, 42 GitHub, GitLab or npm tokens and 23 AWS keys.

The mechanism is in Anthropic's permissions docs. When a user picks "Yes, and don't ask again" on a shell command, Claude Code saves an allow rule in that file. If the prompt offered the exact command, any password typed into it is saved in plain text. Claude Code adds the file to the user's global git excludes, but that covers one machine only, and nothing goes into the project's own .gitignore. In 539 of 1,105 traced repositories, a commit listing Claude as co-author changed the file.

gitleaks caught 564 of the 1,122 files and TruffleHog 643. Neither caught 215. Most misses are passwords after PGPASSWORD=, sshpass -p or mysql -p, which look like ordinary words to a scanner built for key formats. Apiiro sells security products and did not test whether the secrets work. One company it notified confirmed its key was live.

Rotate first. Then run git rm --cached .claude/settings.local.json and add the file to the repository's .gitignore. Older versions stay in history: Apiiro found 734 more secrets there that no current copy holds.

Do you scan agent config files for secrets, or only source code?

Sources: Apiiro research (Nov 5), The Hacker News (Nov 7).

OpsShield's incident notice says an attacker used compromised credentials to push fake cPGuard updates (5.88.12 to 5.88.19) at 02:06 UTC on Nov 2. The update ran as root. OpsShield estimates about 2,950 servers executed it, and the script collected /etc/shadow and the root MySQL config. It also took root's shell history and SSH files. Help Net Security adds that about 7,900 billing-portal accounts (names, emails, bcrypt hashes) were copied too.

To see whether a server installed an affected version, OpsShield gives this check:

grep 'Successfully updated' /opt/cpguard/logs/install_log

A match only proves the update was installed, not what was sent out. OpsShield's advice for those servers: update to 5.88.26 or later and reset root and other local passwords from a trusted environment. Then rotate database and cloud keys, and replace the SSH keys under /root/.ssh. It says a full rebuild is not routine, but that is provisional.

Question for people who run hosting servers: do you let security agents auto-update as root on their own schedule, or stage updates first? And how would you have noticed a 70-minute window like this one?

Sources: OpsShield notice (Nov 3), Help Net Security and SecurityWeek (Nov 4).

Security reports to WordPress on HackerOne sat at 20 to 30 a month for about a decade, then hit 450 in July and 773 in August, and John Blackbourn posted the graph with the reason attached: people now point Claude and GPT at core and let them read.

Click2Shell is what one of those bugs looks like. Fixed in 7.1.1, found by pwn.ai with Claude Opus 5 and one human in the loop, and the entire attack is a link. An admin who's logged in opens it, WordPress's own JavaScript clicks Install on a theme from the official catalog for them, the

Customizer loads that inactive theme's PHP, and a sloppy AJAX handler inside the theme pulls in whatever the attacker wants. The site's theme never changes. Nothing in the firewall log looks wrong, because every request came from the admin's own browser carrying the admin's own nonce.

So on the day that link went around, the firewall wasn't the variable. The variable was how many people could open it while logged in as Administrator.

I'm going through ours now and I already know the answer on a couple of client sites is going to be embarrassing, because "the client needs admin" was always the easiest ticket to close.

How many Administrator accounts are on the sites you look after? I'm asking because I suspect my number is normal and I don't like that.

Two core security releases in five days, and the second one is the bad one. 7.1.2 went out on the 22nd for a page-template bug in core that needs no account and no click, and Patchstack was seeing probes for it the same afternoon. CISA added it to the KEV list on the 25th. If you patched to 7.1.1 last week and stopped there, you're still open.

The reply I keep getting when I bring this up is "auto-updates are on, we're fine."

Go open wp-config on the site you're least worried about. If there's a WP_AUTO_UPDATE_CORE set to false in there, left over from some migration or a dev who wanted control back in 2021, that site hasn't updated itself since 2021, and nothing in the dashboard is going to tell you. Same with DISABLE_WP_CRON when the host promised a server cron, and nobody ever set one up. The update check simply never runs. The site sits there looking maintained.

I ran wp core version across ours yesterday instead of trusting the version number on the dashboard. I don't normally do that. I probably should have been doing it for years.

What actually bothers me is who ends up behind. Not the neglected side project on cheap shared hosting; that one auto-updated on the 22nd without anyone noticing. It's the client site with change control and a staging step, where the 7.1.2 ticket is still waiting on a reviewer who's on holiday until Monday.

Did you check every site you're responsible for, or did you see the auto-update line and move on? I'm asking because I'm not sure which one I'd have answered a month ago.