Oracle E-Business Suite Flaw Draws Exploit Attempts Days After Patching

CVE-2026-101767 is a critical Oracle E-Business Suite vulnerability fixed in Oracle’s October Critical Patch Update. This post explains how the attack works, what activity has shown up so far, and what EBS operators should do now.

What You Need to Know

Attackers are already probing a 9.8 CVSS flaw in Oracle E-Business Suite (EBS), only days after Oracle released a fix. The vulnerability allows unauthenticated SQL injection that can be chained to remote code execution. If you run EBS, whether it’s internet-facing or not, treat this as a priority patch and check whether untrusted networks can reach the vulnerable endpoint.

What Happened

CVE-2026-101767 affects the Oracle Application Object Library. Horizon3.ai researchers Brandon Peterson, Jimi Sebree, and Noah King found the flaw and reported it to Oracle on July 24, 2026, and Oracle shipped the fix in its October Critical Patch Update. On October 27, Defused Cyber reported exploratory exploitation attempts against its EBS decoys, so attackers are already testing the newly patched entry point. Those attempts hit decoys. Nothing in the report confirms compromise of production environments, and that’s worth keeping in mind when you assess the current threat.

How the Attack Works

The attack starts with a crafted request to the Thin Client Framework servlet at /OA_HTML/AppsTCFServer. An attacker who can reach that endpoint can run SQL with the privileges of the APPS database user, then chain that into operating system command execution under the EBS application account. Host-level access is limited to that account’s permissions, so it doesn’t automatically give the attacker full administrative control.

Why This Matters

The flaw exposes both business data and the application host. Depending on the deployment, that data may include financial, payroll, HR, and procurement records, which is exactly what EBS is built to hold. Internet-facing deployments are the most urgent, but internal systems aren’t safe either. An attacker with a foothold elsewhere in the environment could reach the same servlet from an accessible network segment and use it to expand access.

What to Do

Install the Oracle security update for your EBS version and check whether /OA_HTML/AppsTCFServer is reachable from untrusted networks. If you can’t patch right away, Horizon3.ai recommends removing /OA_HTML/AppsTCFServer, associated with oracle.apps.fnd.tcf.SocketServer, from the EBS URL firewall allowlist and restricting web-tier access to trusted networks.

To investigate, correlate unauthenticated POST requests to that endpoint with the database and host activity that follows, especially requests that instantiate oracle.apps.jtf.gantt.server.GanttDataServer. Other warning signs include database reconnaissance after unauthenticated web traffic, unexpected files in $APPLPTMP, and the oracle account spawning /bin/sh through Concurrent Manager. Weigh these signals together, since one request on its own doesn’t prove compromise. Patching closes the entry point, but only your application, database, and process telemetry can show whether anyone reached data or ran commands before you remediated.

Adobe Patches Eight Critical Campaign Classic Flaws

Adobe has fixed eight critical vulnerabilities in Campaign Classic, plus a separate critical flaw in Adobe Connect. Here’s what’s affected and what teams running either product should do.

What You Need to Know

Adobe patched eight Campaign Classic vulnerabilities, with CVSS scores from 9.1 to 9.9, that could allow arbitrary code execution, security feature bypass, and privilege escalation. Adobe says it isn’t aware of exploitation in the wild, but every affected deployment still needs to be found and upgraded. The Adobe Connect flaw needs its own update.

What’s Vulnerable

The flaws affect Campaign Classic version 7.4.4 build 9402 and earlier on Windows and Linux. Version 7.4.4 build 9403 fixes them.

The Details

Three of the vulnerabilities, each scored 9.9, could allow arbitrary code execution: CVE-2026-104351 (code injection), CVE-2026-104353 (operating system code injection), and CVE-2026-105780 (incorrect authorization). Four SQL injection flaws could allow security feature bypass: CVE-2026-105489 (9.9), CVE-2026-105781 (9.8), and CVE-2026-104354 and CVE-2026-105779 (both 9.1). The eighth, CVE-2026-104350, is a reflected cross-site scripting vulnerability rated 9.3 that could lead to privilege escalation. These are separate weaknesses with different potential outcomes. Nothing reported so far documents them as an exploit chain, and the reported impacts don’t confirm that every flaw allows unauthenticated compromise.

Adobe also fixed CVE-2026-48360, a critical code injection vulnerability in Adobe Connect Desktop and Mobile with a CVSS score of 9.6. Fixed versions are Connect Desktop 2026.9.61 for Windows, 2026.10.66 for macOS Silicon, and 2026.10.170 for macOS Intel, plus Connect Mobile 4.5 for Android.

Why This Matters

With no known exploitation, there’s no attacker activity to report, but that doesn’t make patching any less necessary. This is a patch release and should be communicated as one, rather than as an active attack. The bigger operational problem is the version number. The affected and fixed releases are both 7.4.4, so a quick version check can make a vulnerable system look current. Focusing only on the highest-scoring code execution flaws would also leave the SQL injection and XSS issues open.

What to Do

Inventory Campaign Classic installations on both Windows and Linux, check their build numbers, and upgrade anything at build 9402 or earlier to build 9403. After deployment, confirm the installed build and test essential application workflows before closing remediation records. Plan remediation around all eight flaws. If you also run Adobe Connect, track those updates separately, since upgrading Campaign Classic does nothing for vulnerable Connect clients. Because the vulnerable and fixed releases share a version number, the build number is the only reliable way to confirm you’re done.

CISA Confirms Active Exploitation of Node2Shell Brotli Flaw

Node2Shell (CVE-2026-111497) is a critical Brotli decoder vulnerability that’s now in CISA’s Known Exploited Vulnerabilities (KEV) catalog. We cover what it affects and how to find and fix it.

What You Need to Know

CISA has confirmed active exploitation of Node2Shell, a flaw in the Brotli decoder that lets a remote, unauthenticated attacker corrupt decoder memory with a crafted compressed stream. It was first found in Node.js, but it affects any HTTP server or client using a vulnerable Brotli implementation. Federal agencies have until November 10 to remediate, and everyone else should prioritize it now.

What’s Vulnerable

CVE-2026-111497, also called Broccoli2Shell and HTTP2Shell, is in the Brotli decoder rather than any single product. Node.js is just where researchers spotted it first, so the decoder is a better inventory target than any product name.

The Details

The bug is an unchecked return value that can lead to an out-of-bounds write and corrupt adjacent decoder state. A maliciously crafted Brotli-compressed stream can trigger it. Possible consequences include denial of service, disclosure of sensitive memory contents, and, under certain conditions, arbitrary code execution. Code execution isn’t guaranteed on every deployment, but crashes and memory disclosure are serious on their own.

CISA added the vulnerability to the KEV catalog on October 27, with a November 10 remediation deadline for covered federal agencies. The report doesn’t identify the attackers, the targeted organizations, or the scale of exploitation. Separately, Microsoft released an emergency .NET security update on October 25, warning that exploitation could allow privilege escalation on systems running vulnerable .NET versions.

Why This Matters

Because the flaw is in a shared decompression library, exposure is hard to spot. It can hide in runtimes, HTTP components, and container images that nobody thinks of as “Node.js applications.” Impact also varies by product, from crashes to memory leaks to the privilege escalation Microsoft warned about for .NET, so check vendor-specific guidance to know which updates apply. Exploitation is confirmed, but nothing in the reporting points to a broader named campaign, and the two shouldn’t be conflated.

What to Do

Identify applications, runtimes, HTTP components, and container images that include affected Brotli implementations, then apply the relevant vendor updates. Start with exposed services that process attacker-controlled compressed data, and check client-side decoding paths too. Public-facing Node.js servers are only part of the picture.

If you can’t deploy updates immediately, block incoming Brotli-compressed requests at a capable proxy or firewall, or disable Brotli decoding until patching is done. Then confirm the control actually stops affected components from processing the compressed stream. After updating, restart affected processes and rebuild and redeploy vulnerable container images so running workloads pick up the fixed components. Record those steps in remediation tickets. An updated package on disk doesn’t prove every running application and deployed image has been replaced, and the fix only counts once the running workload is using it.

Microsoft Pulls Trust in eMudhra Certificates After Private Key Exposure

Microsoft has issued emergency trust updates after private keys from eMudhra’s intermediate certificate authorities were exposed. This covers what changed in Windows and Edge and what administrators should verify.

What You Need to Know

Eight intermediate certificate authority private keys in eMudhra’s certificate hierarchy were exposed, which would let attackers impersonate trusted websites or sign malware with legitimate-looking certificates. Microsoft responded with out-of-band trust updates for Windows and Edge. There’s no confirmation that the keys were abused, but the trust changes may break legitimate services that depend on the affected chains.

What Happened

According to eMudhra’s incident report, weak key generation left the affected keys open to potential recovery. Six of the eight keys supported TLS and two supported code signing. The incident started in eMudhra’s certificate hierarchy. Microsoft’s own systems weren’t breached, and Microsoft’s statement doesn’t establish that attackers used the keys against customers.

The Details

Microsoft’s response involves two separate trust changes. On October 20, Microsoft updated the Windows Disallowed Certificate Trust List to block the affected intermediate certificate authorities. A separate CRLSet update blocked affected TLS certificates in Edge and WebView2 through automatic component updates, with no new browser version needed.

Microsoft then widened the response. On October 26, 2026, it issued an out-of-band Windows trust-list update removing seven certificates: six eMudhra G3 root certificates and an AAA Certificate Services cross-sign. It applied the same removals to Microsoft Edge on October 27. These seven removed certificates are different from the eight exposed intermediate keys, so don’t treat the two counts as interchangeable.

Why This Matters

Blocking specific intermediates only targets the compromised authorities. Removing higher-level trust anchors reaches further and can affect other certificate chains that depend on them. As the changes reach endpoints, organizations may see trust failures in legitimate services, and there will be pressure to restore trust locally. Doing that undermines the protection the updates are meant to provide. Coverage also has gaps: software that skips revocation checks or ignores Microsoft’s disallowed-certificate list may still accept affected chains.

What to Do

Verify that Windows certificate trust updates and Edge component updates are reaching managed systems, including devices outside normal update paths. Disconnected environments need extra attention, since you may have to distribute trust-list changes through an internal file or web server. Microsoft also advises reviewing disconnected Azure virtual machines and Virtual Machine Scale Sets, and updated images are available through Azure Marketplace.

At the same time, identify certificates that chain to the seven removed certificates and arrange replacements or another trusted chain before you reach for exceptions to fix compatibility failures. Check application-level validation too. Oracle Java has its own guidance for distrusting the affected eMudhra intermediates. Finally, confirm both that the updates were delivered and that affected certificates are actually rejected, because a current Windows or browser version doesn’t prove the trust relationships are gone. When a chain breaks, replace it instead of restoring trust in it, even though restoring trust is the faster fix.

FortiBleed 2.0 Exposes FortiGate Secrets Beyond Firewall Logins

Hudson Rock’s FortiBleed 2.0 research looks at cleartext secrets in leaked FortiGate configuration reports. We cover what the data does and doesn’t show, and how to respond if your organization is affected.

What You Need to Know

The investigation found 40,573 records containing cleartext secrets in FortiGate configuration reports, including Active Directory LDAP bind, SMTP, and high-availability cluster credentials. Those secrets can support access well beyond the firewall itself. If your configuration was exposed, a firewall password reset isn’t enough. Treat it as a credential response rather than only a patching task.

What Was Exposed

The research, published October 27, 2026, examined 1,703 configuration reports containing 101,419 credential and account records linked to 1,689 host identifiers. Recovered secrets included 37,076 local-user entries, 1,576 Active Directory LDAP bind entries, 1,672 administrative logins, 144 high-availability cluster secrets, and 105 SMTP credentials. Researchers also identified 975 domain labels that weren’t in the earlier FortiBleed dataset.

Some FortiOS configuration secrets use reversible encryption, and researchers can recover values protected with the system-default encryption key offline. Whether recovery works depends on the firmware, the configuration, and what material was obtained, and device-specific encryption keys can change that risk.

What the Data Does and Doesn’t Show

Several of these numbers are easy to misread. The 975 new domain labels aren’t 975 newly breached organizations, since some may belong to service providers or email services rather than victims. Most dated reports carry February 20, 2026 timestamps. Those are report dates, and they haven’t been independently verified as dates of intrusion or configuration theft. The reported toolchain combines configuration parsing, secret recovery, VPN connection attempts, and checks against internal systems, but a recovered credential doesn’t mean anyone successfully authenticated with it.

Other details need the same care. Researchers found 7,437 cleartext local-user records marked disabled. Administrative accounts labeled verified reflect the source dataset, not fresh login tests. A blank MFA field doesn’t prove MFA was off, and an exposed LDAP password doesn’t automatically mean domain administrator privileges. No single entry method has been established for every host in the dataset.

Why This Matters

A firewall configuration maps the trust relationships around it. LDAP bind credentials connect the appliance to directory services, and SMTP and cluster secrets support other operational links. When those leak, the risk moves from the edge device to the directory, mail, and high-availability infrastructure behind it, with follow-on access depending on account permissions and network controls. Since no single vulnerability explains every case, patching won’t close the exposure by itself.

What to Do

Start by validating the records against your own assets. Hudson Rock’s lookup portal can help identify potential domain exposure, but confirm any match before declaring a compromise. If you confirm a secret was disclosed, end administrative and VPN sessions, reset affected user and administrator credentials, and rotate LDAP bind, high-availability, and SMTP secrets, updating the services that depend on them.

Enforce MFA, update FortiOS, and restrict management access to trusted networks. Compare current configurations against trusted backups, investigate unfamiliar accounts or policy changes, and correlate firewall authentication activity with domain controller logs for signs of internal movement. Don’t assume one vulnerability explains how your configuration got out. Deal with the exposed credentials and configuration integrity directly, since every credential in a leaked config is exposed and each one needs its own rotation.