The Patch Was Ready Five Weeks Ago. Were You?

Last weekend, while most of us were winding down for the week, attackers were busy exploiting a critical flaw in Oracle's payment-processing engine. Not a theoretical risk. Not a proof-of-concept floating around GitHub. Real attacks, hitting real systems, targeting the component that handles how your organization sends and receives payments through banks and card networks.

The vulnerability — CVE-2026-46817, rated 9.8 out of 10 on the severity scale — lets an unauthenticated attacker take over Oracle Payments through a simple HTTP request. No credentials required. No sophisticated tooling. Just a crafted request to a specific endpoint, and the attacker owns your payment system.

Here's what should keep executives up at night: Oracle released the patch on May 28. Five weeks later, approximately 950 Oracle E-Business Suite instances remain exposed to the public internet, most of them in the United States. And on June 27, threat intelligence firm Defused detected the first in-the-wild exploitation on their honeypot systems — before any public exploit code even existed.

That means someone invested the time and resources to reverse-engineer Oracle's patch, build a private exploit, and start scanning for targets. Within four weeks of the fix being available.

The Numbers Tell a Story

By June 28, Shadowserver recorded 456 exploitation attempts in a single 24-hour period, spread across every inhabited continent. North America absorbed the largest share. This wasn't a targeted campaign against one company — it was broad, automated scanning looking for any unpatched Oracle EBS instance reachable from the internet.

The attackers targeted the ibytransmit endpoint in Oracle Payments' File Transmission component. The initial payloads were reading system files from the server — the digital equivalent of testing whether the door is unlocked before walking in. But the same technique could reach configuration files containing database credentials, encryption keys, or payment processor API keys.

In my experience, when attackers start with file reads on a payment system, data exfiltration and financial fraud aren't far behind.

This Is a Board-Level Conversation

I talk to executives constantly who believe their organization has patching "under control." But CVE-2026-46817 is a textbook example of the gap between policy and execution.

Ask yourself — or better yet, ask your CISO — the Three Questions I lay out in Cyber Risk Is Business Risk:

What can go wrong? An unauthenticated attacker can take full control of your payment-processing system. That means potential access to bank routing information, payment credentials, and the ability to redirect transactions. The reputational, financial, and regulatory consequences of a compromised payment system should be obvious.

What are we doing about it? Oracle released the patch five weeks ago. If your team hasn't applied it yet, the follow-up question is why. Is it a resource problem? A testing bottleneck? A lack of visibility into what's running in your environment? Each answer points to a different systemic issue that goes beyond this single vulnerability.

How would we know if something went wrong? Are your security operations teams monitoring for exploitation attempts against this specific endpoint? Do you have logging in place that would catch unauthorized file reads on your EBS servers? If the answer is "I'm not sure," that's the answer.

The Patching Gap Is a Governance Gap

Here's the pattern I keep seeing: a vendor releases a critical security update, the security team flags it, and then it enters a queue behind change management processes, testing cycles, and competing priorities. Meanwhile, attackers are reverse-engineering that same patch to build their exploit.

Four weeks. That's the window between Oracle's fix and the first attacks. Your organization's patch cycle needs to beat that timeline for critical vulnerabilities — especially those affecting payment systems.

This isn't a technology problem. It's a governance problem. Boards that treat cybersecurity as an IT issue rather than a business risk issue end up with five-week patching gaps on systems that process their payments. The question isn't whether your IT team knows about the vulnerability. The question is whether the organizational structure, priorities, and resources allow them to act fast enough.

What to Ask Your CISO This Week

If your organization runs Oracle E-Business Suite, here are the questions that matter right now:

1. Have we applied Oracle's May 2026 Critical Security Patch Update? If not, what is the specific timeline and what's blocking it?
2. Is any part of our EBS deployment reachable from the public internet? Given the pattern of repeated critical EBS vulnerabilities over the past year, security teams should be questioning whether any internet-facing EBS components are necessary at all.
3. Do we have monitoring in place for exploitation attempts against this vulnerability? Specifically, suspicious POST requests to the /OA_HTML/ibytransmit path.
4. What is our mean time to patch for critical vulnerabilities on financial systems? If the answer is longer than four weeks, you have a governance problem, not a technology problem.

The attackers who built this exploit didn't wait for a public proof-of-concept. They invested resources to reverse-engineer a patch and automate exploitation across every continent — all within a month. The question for your organization is straightforward: can you move faster than they can?