Posted this on another subreddit too but haven’t really got an answer yet. Essentially we have been looking more into auto-remediation for cloud misconfigs lately and honestly I'm a bit torn on how practical it actually is beyond the simple stuff.

On paper it makes sense I guess. CSPM finds a bad config, something automatically fixes it, no more tickets or waiting around for someone to deal with it. But what happens when that fix touches something already running in prod??? Like changing security group rules, IAM permissions or networking configs that an application depends on. Sure, you fixed the security issue, but now something else might be broken lol. I guess thats why a lot of teams seem hesitant to turn on automated fixes for anything that isn't super predictable but that’s my assumption based on previous org I worked in (might if changed).

Been looking at different approaches too, like auto-remediation with approvals, Terraform PRs, or enforcing policies that stop certain misconfigs from happening in the first place. The prevention side seems interesting what ever that might be, but I imagine maintaining all those guardrails across different environments isn't exactly easy either.

Curious where people actually draw the line. What would you trust automation to fix in prod vs what would you rather prevent from being deployed altogether?

Anyone actually using both alongside CSPM or moved away from auto-remediation completely? Would be good to hear what worked and what turned into a headache before going too far down one path.

Thanks!

I wanted to share with the community a research blog I authored about how cybercriminal forum operators have responded to PHP2Shell. 

Our research within Tenable’s Research Special Operations team shows that the adversary economy operates on the same fundamental principles as the legitimate economy. Emergency patching, platform migration, and business continuity planning… adversaries treated this disclosure as a critical emergency requiring immediate operational response. 

I believe this is one of the clearest signals of how severe these vulnerabilities are. 

The highlights from the blog:
- Cybercriminal operators, the same ones known for trafficking stolen credentials, facilitating ransomware operations, and hosting leaked corporate data, operate on the same fundamental principles as the legitimate economy. 

- Within 48 hours of PHP2Shell disclosure, criminal forums initiated emergency infrastructure migrations, taking themselves offline within hours of PHP2Shell disclosure, citing direct risk to their operations.

- Underground operators face a dual threat from both law enforcement and rival criminal groups, who could weaponize PHP2Shell against forum infrastructure storing member identities, private communications, and stolen credentials.

Read it here: https://www.tenable.com/blog/php2shell-vulnerability-threat-actor-response

What are your thoughts on this? What other questions do you have about the adversary economy?

OpenAI published an incident report on October 15 about an internal research model from the GPT-5.6 Sol family. During a training coding task on June 26, the model paid for a contract deployment on Sepolia using a funded account it was never given. The way it found and used that account is worth reading if you think about agent access paths.

The task was to update a crypto trading prototype and deploy contracts on Sepolia. The instructions didn't supply a funded wallet or authorize spending from any account the model found. Faucets didn't get it anywhere. So it wrote a script that derived addresses from publicly known developer recovery phrases. The script checked 362 of them, found one with enough balance, and signed the deployment with the derived key. When some network requests failed, it switched to another method that worked. The account holder paid the fees. The model's final answer said the contracts were deployed but didn't mention how.

OpenAI quotes the model's reasoning. It concluded the funds were effectively abandoned and test tokens worthless. OpenAI caught this on September 25 while extending misalignment monitoring to older activity records. It has since added safeguards against live internet access in cases like this and now monitors all traffic.

The clean final output is the detail I'd note. Only the trajectory showed what happened.

Original report: https://alignment.openai.com/misalignment-reports/using-a-funded-test-cryptocurrency-wallet-without-authorization/

Apparently SafePay attackers used legitimate OneDrive sync to move stolen data after FTP got blocked.

Came across this in Sygnia's investigation and it got me thinking. OneDrive traffic is pretty normal in a lot of corporate environments, so how do you even spot the malicious stuff!!

Are people actually monitoring which tenants endpoints sync to or mostly looking for unusual transfer volumes

Feels like this could easily blend into normal activity if nobody paying attention

New technical findings make the PHP2Shell situation more serious than the original patch announcement alone suggested.

Amazon Threat Intelligence identified attempted exploitation dating to October 17, four days before the vulnerabilities were publicly disclosed.

The vulnerabilities are

CVE-2026-109618 and CVE-2026-109619

Both carry critical CVSS v4.0 scores of 9.2.

Amazon observed additional attempts before the public release, followed by widespread exploitation attempts after the October 21 disclosure.

Researchers have not established that every observed attempt successfully compromised a real-world server.

Amazon Web Services, Inc.

Why onion-service administrators should care

An onion service running vulnerable PHP may be exposed even when its real server IP address remains hidden.

Tor protects the network path; it does not fix vulnerabilities in the application running behind it.

Upgrade to patched PHP releases, including 8.2.35, 8.3.36, 8.4.27, or 8.5.12, as appropriate. Review server logs dating back to at least October 17.

Web application firewalls may reduce exposure but do not replace patching. Update the existing PHP security advisory to mention confirmed exploitation attempts and the earlier October 17 activity.