The Red Thread Weekly Wrapup: Issue #21
Categories: IT Risk Management | Information Security | Penetration Testing
I spent part of this week reviewing how several recent security incidents developed, and the same problem kept appearing: time.
Not technology. Not a lack of security products. Time.
An attacker now has the ability to move from an exposed entry point to sensitive systems in hours. A public proof of concept can turn a patching decision into an emergency. A forgotten vendor integration can preserve access long after everyone has stopped thinking about it. A routine backup account can quietly carry more authority than anyone intended.
After 26 years in cybersecurity, including work with EY, East West Bank, and Nano Banc, I have learned that security failures rarely begin with one dramatic mistake. They usually begin with an assumption that used to be reasonable.
This week’s stories show those assumptions breaking down.
AI has changed the speed of the break-in
Unit 42 published an account of an enterprise intrusion in which a human attacker used frontier AI models and purpose-built agentic frameworks to automate much of the operation.
The result was not a theoretical demonstration. The attacker used AI agents to map internal services, search code repositories for hard-coded credentials, access a secrets-management system, take control of cloud keys, and interfere with development pipelines. Unit 42 observed more than 50 attack techniques carried out in less than 10 hours.
The researchers estimated that the same work would normally require a coordinated human red team approximately two weeks to complete.
The important detail is that the attacker did not need a previously unknown vulnerability. The intrusion relied on familiar weaknesses: exposed application interfaces, secrets stored in code, excessive cloud permissions, and insufficiently protected development workflows.
The speed changed the business calculation.
If an attacker can discover, test, and chain weaknesses faster than a company can review an alert, approve an emergency change, and revoke access, then a security program built around manual response is already behind. A weekly review cycle may once have been acceptable. It is not a serious answer to an attack that can move through an environment before the next meeting on the calendar.
The practical lesson I take from this is that executives need to ask a different question. It is not simply, “Do we have tools that detect suspicious activity?” It is, “How quickly can we contain a credible compromise across identity, cloud access, development systems, and data?”
That answer should be measurable. It should also be tested.
A penetration test can show whether an attacker can move through a known path. A broader technical testing and vulnerability scanning program can help identify the exposed conditions that make rapid movement possible. But the value is not in receiving another technical report. The value is in knowing who owns each fix, how quickly it will be completed, and what happens when the business cannot remediate immediately.
Exchange turned a patch into a deadline
Microsoft Exchange vulnerability CVE-2026-62911 is a different kind of warning.
A working public exploit reportedly allows an attacker to compromise exposed on-premises Exchange servers without supplying a password. Shadowserver scans identified approximately 21,899 unpatched servers worldwide as of August 31, including roughly 6,200 in the United States and 5,100 in Germany.
The vulnerability affects a service used for mailbox replication. Through a credential-relay chain, an attacker can reach a method that writes a webshell with SYSTEM-level privileges. In plain business terms, that can mean access to mailboxes, attachments, credentials, and the server itself.
Microsoft shipped a patch on August 11. Public proof-of-concept code appeared on August 27. That gap is the part executives should pay attention to. Once technical details and working exploit code become public, the organization is no longer operating on a normal patch schedule.
For companies still running Exchange 2016 or 2019, the problem is more serious. Security updates require Microsoft’s paid Extended Security Update program, and that program ends permanently on October 31, 2026. There will be no further extension.
That makes software end-of-life a financial and legal decision, not merely an IT housekeeping issue. The choices are straightforward even if neither is easy: fund the supported security path or accelerate migration. Deferring the decision does not preserve flexibility. It preserves exposure.
I have seen executives treat legacy systems as stable because they are familiar. Familiarity is not the same as safety. A system can be reliable for daily operations and still be a liability when its security support ends.
I would put this issue on the executive risk register with a named owner, a funded plan, and a date. I would also confirm whether the server is internet-facing, whether the patch was actually applied, and whether there are signs of compromise. A vulnerability scan can help establish exposure, but patch status and containment decisions require accountable follow-through.
The same pattern appeared in a widely used WordPress tool this week. Elementor Pro vulnerability CVE-2026-32475 reportedly generated nearly 200,000 blocked exploitation attempts after the August 19 patch. Widely deployed tools attract attackers because one weakness can create a large return. Popularity is not a security control.
Trust between vendors does not expire by itself
Dropbox disclosed that approximately 5,000 accounts were compromised between August 4 and August 21 through a legacy Lenovo single sign-on integration.
The reported issue involved Lenovo’s email-verification process. Attackers were able to register Lenovo IDs using victims’ email addresses and then access the corresponding Dropbox accounts without needing the Dropbox password. None of the affected accounts had two-factor authentication enabled.
Dropbox severed the integration, expired sessions, and advised affected users to reset passwords and enable two-factor authentication. Those were appropriate actions, but they came after the inherited trust relationship had already become an access path.
This is where vendor management becomes a business issue rather than a procurement exercise.
When two providers are connected, each organization may assume the other is responsible for identity verification. The vendor sees a valid account relationship. The customer sees a familiar brand. Legal sees a contract. Security sees a federation connection that may not have been reviewed since the original implementation.
The risk sits between those perspectives.
I want every executive team to know which external services can access company data, how that access is verified, and who owns the relationship. I also want those connections reviewed when a service changes, when a vendor is acquired, and when the original business purpose disappears.
A useful data governance framework should connect data classification to vendor access. If a third party can reach sensitive employee records, financial information, customer files, or intellectual property, that relationship deserves more than a standard questionnaire. It needs clear ownership, appropriate contract terms, ongoing monitoring, and a defined offboarding process.
The quiet question is often the most important one: if we ended this relationship today, could we prove that every access path had been removed?
The accounts nobody watches can hold the keys
Researchers at Cyera disclosed PostGREShell, tracked as CVE-2026-6471, a PostgreSQL vulnerability that remained unnoticed for more than a decade.
The flaw affected versions dating back to PostgreSQL 9.4, released in 2014. A low-privileged account with the REPLICATION attribute, commonly used for backups, replicas, monitoring, change-data-capture pipelines, and migrations, could load and execute arbitrary code on the database server.
From there, an attacker could escalate to PostgreSQL superuser access and establish persistent control.
This is a useful reminder that “low privilege” is not always low risk.
The label attached to an account does not tell me what that account can ultimately reach. A backup account may not be allowed to read every application screen, but it may have the ability to copy nearly every database record. A replication account may not be a human administrator, but it may sit directly on a path to the system that stores the organization’s most valuable information.
Windows environments carry additional exposure because malicious libraries could potentially be loaded remotely through SMB. The supported PostgreSQL releases were patched on August 13, but the age of the flaw demonstrates why patching alone is not a complete control.
I would start by building an inventory of service accounts and documenting what each one can access, what systems depend on it, and whether it is still required. I would then review authentication activity, outbound connections, database extensions, and persistence mechanisms associated with those accounts.
This is where data governance and IT risk management meet technical reality. If leadership cannot identify where sensitive data resides, which accounts can reach it, and how those accounts are monitored, then the organization is managing systems without understanding its exposure.
The four stories this week point to one conclusion. The adversary is moving faster, while trust and access are lasting longer than the assumptions behind them.
I do not think every company needs to react with panic. I do think every company needs to replace annual reassurance with continuous accountability: current asset inventories, tested response times, reviewed integrations, constrained service accounts, and a clear plan for systems approaching end of life.
The takeaway is simple: security decisions must now be made at the speed of the risk, not the speed of the old process.
If you are unsure which legacy systems, vendor connections, or quiet service accounts deserve attention first, I am always open to a practical conversation.
Comments