# One Encoded Letter Walked Past the Firewall

> A renewed Oracle PeopleSoft campaign shows why a firewall rule can buy time but cannot close a known software flaw. Here is how to patch, look back, and prove the risky path is gone.

- **Author:** Kubilay Tunca
- **Published:** 2026-09-27
- **Category:** For Developers
- **Tags:** Vulnerability Management, Incident Response, Application Security, Platform Security
- **Canonical URL:** https://cyber-security-in-plain-english.com/post/developers/news/peoplesoft-firewall-rule-was-not-a-patch

---

A security team blocks `/PSEMHUB/` at the web application firewall. The forbidden path stops appearing in the firewall log. The dashboard looks quiet, and the emergency change ticket can finally be closed.

Then an attacker asks for the same path with one letter written as `%50` instead of `P`.

The firewall compares the text it received and misses the blocked spelling. The application decodes `%50` back into `P`, routes the request to the same vulnerable PeopleSoft component, and runs it. One system sees two different paths. The next system sees one.

That small disagreement sits at the centre of a renewed Oracle PeopleSoft campaign that Google Threat Intelligence Group and Mandiant described on 25 September 2026. It is also a useful test of how we think about emergency mitigations. A rule at the edge can reduce exposure while a team prepares a repair. It cannot make the vulnerable code stop being vulnerable.

## What happened in September

The affected flaw, CVE-2026-35273, is in the Updates Environment Management component of Oracle PeopleSoft Enterprise PeopleTools. Oracle published an out-of-band security alert on 10 June 2026 and lists supported PeopleTools versions 8.61 and 8.62 as affected. Oracle says an attacker with network access can exploit it over HTTP without a username or password, and that a successful attack can take over PeopleTools. The vendor assigns it a CVSS score of 9.8 out of 10 and tells customers to apply the security alert without delay ([Oracle](https://www.oracle.com/security-alerts/alert-cve-2026-35273.html)).

That June alert followed attacks observed between 27 May and 9 June. On 12 June, the US Cybersecurity and Infrastructure Security Agency added the flaw to its Known Exploited Vulnerabilities catalogue, the list it uses for vulnerabilities with evidence of real exploitation. Federal civilian agencies received a 15 June repair deadline ([CISA](https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json)). Those dates matter because this was no longer a hypothetical defect waiting for a clever researcher. There was a vendor repair, an exploitation record, and a short official deadline.

The September news is a second wave. Mandiant says the group it tracks as UNC6240, also known as ShinyHunters, changed its requests to pass through path-based web application firewall rules. The earlier rules looked for the literal string `/PSEMHUB/`. The new requests used `/%50SEMHUB/`, where `%50` is the web encoding for an uppercase `P`. The firewall could compare the undecoded text while the PeopleSoft application server decoded it before routing. That allowed both spellings to arrive at the vulnerable component ([Google Cloud](https://cloud.google.com/blog/topics/threat-intelligence/shinyhunters-renewed-mass-exploitation-campaign-targeting-oracle-peoplesoft)).

Mandiant reports web shells on dozens of systems across higher education, technology, IT services, healthcare, agriculture, transport, and government. A web shell is a small program planted on a web server so an intruder can send later commands through ordinary web requests. On some Windows servers, the investigators also found a backdoor they call SIDEEYE. Independent coverage from BleepingComputer and The Hacker News matches the published timeline, affected path, encoded-character bypass, and advice to install Oracle's update rather than relying on a firewall rule ([BleepingComputer](https://www.bleepingcomputer.com/news/security/shinyhunters-uses-waf-bypass-trick-in-oracle-peoplesoft-attacks/), [The Hacker News](https://thehackernews.com/2026/09/attackers-bypass-wafs-to-exploit-oracle.html)).

The precise victim count is Mandiant's observation, not a census of every PeopleSoft system. Oracle's public alert confirms the software flaw and repair, but it does not independently confirm the September campaign. That distinction is worth keeping. The evidence supports urgent action without turning an incident report into a claim that every internet-facing server was breached.

## Why the rule looked stronger than it was

A web application firewall, or WAF, sits in front of an application and decides whether an incoming request looks acceptable. It can block a known path, reject a suspicious body, or slow repeated probes. During an emergency, that makes it useful. A team can sometimes place a narrow rule in minutes while testing a vendor update takes hours or days.

The PeopleSoft case exposes the condition hidden inside that usefulness: the firewall and the application must agree on what the request means.

Web addresses have more than one valid textual form. Characters can be percent-encoded. Uppercase and lowercase may or may not matter. A proxy might decode a path once, while an application framework decodes it again. Repeated slashes, dot segments, separators, Unicode characters, and trailing data can also change as a request passes through a chain of products. Security engineers call the process of reducing these variants to one standard representation canonicalisation or normalisation.

Imagine a building where the guard rejects a badge labelled `PSEMHUB`. A clerk beyond the guard accepts encoded badge labels and translates `%50SEMHUB` back into `PSEMHUB`. The guard checked the ink. The clerk acted on the meaning. The attacker did not smash a door; the two desks used different filing rules.

This is why a deny rule built around one observed string has a narrow claim. It says, “requests matching this representation should stop here.” It does not say that every equivalent representation will stop, that no alternate route reaches the component, or that the component itself is safe. Those stronger statements need evidence from the whole request path.

The same lesson applies beyond PeopleSoft. An API gateway may authenticate `/admin` while a backend treats `/admin/` as the same route. A content filter may inspect a compressed or encoded body differently from the service that later expands it. A cache may choose one key while the origin server chooses another. Whenever two controls interpret the same input in a different order, the gap becomes part of the attack surface.

Abandoning edge filtering would throw away a valuable layer. Give that layer an honest job description instead. Use the firewall to narrow traffic, buy time, and collect evidence. Repair the defect where the dangerous interpretation actually occurs.

## A mitigation is a loan against patching time

Emergency mitigations often become permanent by accident. The outage window is hard to arrange. A business owner sees the alert disappear. The change board moves on to the next urgent item. Three months later, the temporary rule has no owner, no expiry date, and no test proving what it blocks.

Treating a mitigation as a loan changes that behaviour. The rule buys a measured amount of time, and the team owes a specific repayment: patch the affected component, disable or remove it where possible, inspect the period before repair, then retire or redesign the temporary control. Interest accumulates as vendor guidance changes and attackers learn what defenders deployed.

In this case, Oracle published the repair on 10 June. Mandiant's September report says the renewed campaign targeted systems where operators had placed WAF blocks in front of the vulnerable PeopleSoft Environment Management Hub but had not installed the update. The campaign did not invalidate every possible firewall configuration. It showed that a common literal path block could be bypassed with a representational change.

That difference should shape the incident ticket. “WAF rule deployed” is an action. “Vulnerability remediated” is a claim. Joining those phrases with an equals sign hides the remaining dependency on parsing behaviour, alternate routes, rule order, and later product changes.

A useful temporary control therefore needs five fields in the ticket: the exact exposure it is meant to reduce, the assumption it relies on, the evidence that tests the assumption, the named owner, and the expiry condition. For the PeopleSoft example, the assumption might say that all external routes to the Environment Management Hub pass through a control that normalises the path before matching it. A test should send harmless variants and verify that none reach the application. Even a passing test still leaves patching as the closure condition.

There is a second debt. Once a flaw has been exploited in the wild, applying the update fixes future entry through that flaw but says nothing about earlier entry. A repaired front door does not remove a key copied last week. The team must pair remediation with a look-back.

## Quiet at the edge does not prove quiet at the server

A firewall log records what the firewall understood well enough to record. That is useful evidence, but it is not the full story of what reached the application. In the September campaign, a query for the literal blocked path could return nothing while encoded variants appeared under a different string. If the analyst searches only for the representation named in the original ticket, silence can be manufactured by spelling.

Mandiant recommends searching PeopleSoft Internet Architecture and WebLogic access logs for requests to `/PSEMHUB/` and percent-encoded variants, particularly POST requests to the hub endpoint and requests for server-side script files. It also recommends inspecting the deployed PSEMHUB application directory for files that are not part of the shipped product, checking endpoints for unexpected remote-management software, reviewing outbound traffic, and rotating credentials readable by the PeopleSoft service account ([Google Cloud](https://cloud.google.com/blog/topics/threat-intelligence/shinyhunters-renewed-mass-exploitation-campaign-targeting-oracle-peoplesoft)).

Those steps point to a broader evidence model. Look at three views of the same event:

1. **The edge view** shows what the WAF, reverse proxy, or load balancer received and how it classified the request.
2. **The application view** shows the path after decoding and routing, the component that handled it, and the response it produced.
3. **The host view** shows files created, processes started, credentials read, network connections opened, and persistence added.

Each view can answer a question the others cannot. Edge logs can reveal broad scanning before the application spends resources on it. Application logs can show the route selected after normalisation. Host evidence can show that a request led to code execution even when a web log looks unremarkable.

Time alignment matters. Keep clocks synchronised and preserve raw timestamps with their time zones. If the proxy logs at 13:04 UTC, the application logs in local time, and an endpoint tool rounds to the nearest minute, an analyst may fail to connect three records from one request. The result is a false gap caused by the evidence system rather than the incident.

Retention matters too. A 30-day application log cannot answer what happened during a May exploitation window when the investigation begins in September. That does not mean every organisation should retain every byte forever. It means retention should match the time it normally takes to discover misuse in that system, and the most important records should leave the server they are meant to investigate.

The US National Institute of Standards and Technology makes evidence collection and preservation part of incident response rather than an optional exercise after containment. Its April 2025 incident-response guidance also frames lessons learned as input to ongoing risk management, which is where this parsing mismatch belongs after the immediate work is done ([NIST](https://csrc.nist.gov/pubs/sp/800/61/r3/final)).

## Patch the component, then prove what is running

“Patched” is another word that becomes vague under pressure. It can mean that a package was downloaded, an installer completed, a change ticket closed, or a scanner stopped complaining. Only one meaning matters to the exposed system: the process handling requests is running repaired code.

Start with inventory. Identify every PeopleSoft environment, including disaster-recovery systems, test copies, migration hosts, old web tiers, and externally reachable addresses that may not appear in the primary asset register. Record the PeopleTools version and the status of the Environment Management Hub for each one. Oracle explicitly names supported versions 8.61 and 8.62, and warns that older unsupported releases are likely affected even though they were not tested in the security alert ([Oracle](https://www.oracle.com/security-alerts/alert-cve-2026-35273.html)). An old version is not cleared merely because it is absent from the supported-products table.

Next, obtain the repair through the Oracle support path named in the alert. Keep the advisory identifier, patch identifier, file hash, approval, installation output, and restart record together. If an installation requires a service restart, the old process remains the active risk until that restart occurs. A package receipt without a runtime receipt is an incomplete handover.

Then verify from two positions. On the host, confirm the installed and active PeopleTools build, the service start time, and the expected application files. From outside the trust boundary, confirm the vulnerable route is no longer reachable or no longer behaves as the vulnerable build did. Do not run a destructive exploit against production. Use the vendor's supported verification method, an authenticated scanner with a safe check, or a controlled request that distinguishes the repaired state without invoking code execution.

Oracle's alert also points to configuration mitigation. In multi-server configurations, the Environment Management Hub can be disabled when it is not required; in single-server configurations, Oracle provides guidance to remove the PSEMHUB application. Mandiant repeats that advice. Removing an unnecessary component is stronger than teaching a perimeter device more spellings of its path because the application server has nothing there to route to.

That choice needs an owner who understands the operational consequence. If a team uses the hub for updates or management, disabling it may break a real workflow. The safe answer is not to leave it exposed without discussion. Document the function, restrict who can reach it, patch it, and place the management path on a network intended for administrators rather than public clients.

Finally, re-run discovery. An asset list built before the emergency will miss systems found during it. Compare DNS, load-balancer pools, cloud inventories, certificate records, vulnerability scans, and traffic logs. The straggler is often a standby node that never joined the main maintenance group, not the server everyone watched during the change call.

## The look-back must include authority, not just files

PeopleSoft commonly sits near data and credentials that matter far beyond one web tier. Payroll, human resources, student, finance, and identity workflows may pass through the application. A service account that can read a database connection string or call another internal service turns one compromised server into a route toward other systems.

That is why a file check alone is too small. Mandiant advises rotating credentials readable by the PeopleSoft application service account, including database connection strings, Integration Broker credentials, and reachable cloud credentials. The important word is “readable.” The rotation set should come from the authority the process had during the exposure window, not from the handful of secrets an investigator already knows were stolen.

Build a simple authority map. Put the PeopleSoft web process in the middle. Around it, list every database, queue, file share, identity provider, management interface, cloud metadata endpoint, backup location, and outbound destination it could reach. Add the credential or machine identity used for each connection. The result does not have to become a perfect architecture diagram before action starts. It must be good enough to prevent a database password from surviving because it lived in an unfamiliar configuration file.

Rotate in a sequence that keeps evidence and service continuity intact. Preserve the necessary forensic material first. Disable confirmed persistence and isolate affected hosts. Replace exposed credentials, update dependent services, and test the new credentials. Revoke the old values rather than merely issuing new ones. Monitor for attempts to use them after revocation.

If the application could mint sessions or sign tokens, consider those artefacts too. Changing a password may leave existing sessions valid. A service account can also have API keys, client certificates, cached tickets, or delegated roles. “We rotated the password” is reassuring only if the password was the whole authority.

The National Institute of Standards and Technology describes containment, eradication, recovery, and improvement as connected work, not isolated checkboxes ([NIST](https://csrc.nist.gov/pubs/sp/800/61/r3/final)). In practice, the authority map links them. It tells the containment team what to cut, the recovery team what to restore, and the detection team what old identity use should now trigger an alert.

## A practical response sequence

A team reading about the September campaign does not need a longer alert queue. It needs an order of operations that separates urgent exposure reduction from durable closure. The following sequence is a practical default for an organisation that owns or supports PeopleSoft.

1. **Name one incident owner and open a time-bounded record.** Put CVE-2026-35273, the Oracle alert, the affected business service, and the decision clock in the first paragraph. Include infrastructure, PeopleSoft administration, security operations, identity, and the data owner. One owner coordinates; the specialists still own their facts.

2. **Find every environment before declaring the scope.** Query the configuration database, virtualisation and cloud inventories, load balancers, DNS, certificates, scanner results, and recent network traffic. Include standby, test, training, migration, and vendor-managed systems. Record unknowns as unknowns rather than silently treating them as absent.

3. **Reduce exposure while the repair is prepared.** Restrict public access, allow only required administrative networks, and disable or remove the Environment Management Hub where Oracle's supported guidance permits it. Keep a WAF rule as an additional layer, but test encoded and normalised path variants. Give every temporary rule an owner and an expiry condition tied to patch verification.

4. **Install Oracle's repair and activate it.** Use the patch path linked from the vendor alert for the exact supported release. Capture the patch identifier, integrity check, installation output, restart, process start time, and active build. Unsupported versions need an upgrade or an isolation decision with an explicit deadline; lack of a vendor-tested patch is exposure, not an exemption.

5. **Search the whole exposure window.** Begin no later than 27 May 2026, the start of the zero-day activity described by Mandiant, unless your own internet exposure began later. Search edge and application logs for decoded and encoded route variants. Inspect the application deployment, running processes, scheduled tasks, services, remote-management agents, outbound connections, and endpoint alerts. Preserve source records before rebuilding a host.

6. **Map and revoke reachable authority.** Identify every secret and identity the PeopleSoft service could read or use. Rotate database, integration, cloud, and management credentials in a controlled order. Revoke old sessions and keys where the surrounding systems support it. Watch for use of revoked identities from unexpected hosts.

7. **Recover from known-good material.** A server with confirmed web-shell or backdoor activity should not return to service because one suspicious file was deleted. Rebuild from a trusted image or follow the organisation's tested eradication standard, restore reviewed configuration, install the repair, and validate data and integrations before traffic returns.

8. **Verify from inside and outside.** Confirm the active build on the host. Confirm the risky component is removed, disabled, or repaired. Test the network path from an untrusted position and the management path from an authorised one. Check that logging still captures both. A control that works only during the change call is not a control.

9. **Close with a receipt, not a feeling.** The final record should list all discovered instances, their active versions, exposure status, patch evidence, look-back period, findings, credential actions, temporary controls still present, and follow-up owners. A manager should be able to read it and know what claim the team can support.

This order avoids two common failures. The first is waiting for a perfect inventory while an exposed component remains reachable. The second is applying a quick block, seeing fewer alerts, and never returning for the repair and investigation. Exposure reduction starts quickly; closure remains evidence-based.

## What the architecture should learn

An incident response that ends with “patch faster” wastes part of the lesson. Patching matters here, but the encoded letter also revealed a design mismatch between components. The platform team can reduce the chance of repeating it elsewhere.

First, choose one place to normalise a request before security decisions are made, and make downstream components consume the same interpretation where the architecture allows it. This is easier to say than to retrofit. Proxies and application frameworks have their own decoding behaviour, and changing it can break clients. That is why the behaviour needs a test suite, not a confident diagram.

Build harmless requests that vary encoding, case, separators, slash count, dot segments, and other forms relevant to the stack. Send them through the complete production-like chain. Record what the edge logs, what route the application selects, and which policy fires. The goal is to find cases where policy compares one representation while code acts on another.

Second, prefer allow rules for sensitive management surfaces. A public application may need thousands of customer routes, but its update hub should usually serve a small set of administrative sources. “Only these management networks may reach this component” survives more spelling variants than “everyone may reach it except requests containing this path.” Network placement is not a patch, but it changes how much untrusted input reaches the parser.

Third, make compensating controls observable. A WAF rule should emit a stable event with the rule version and the normalised path if the product provides one. Application access logs should retain the original request target as well as the route selected after decoding. Without both values, the next investigation may know that a request ran but not how it crossed the edge.

Fourth, rehearse removal. Temporary emergency rules accumulate because nobody knows whether an application came to depend on them. Put the expiry date in the deployment system, alert before it arrives, and run a controlled test after the vendor repair. Keep a useful defence-in-depth rule if it still has a clear purpose. Remove folklore that nobody can explain.

The larger model is simple: every interpreter is a boundary. A firewall parses text. A proxy parses and rewrites it. A framework decodes it. An application maps it to an action. Security holds only when those interpretations compose safely, or when a later layer remains safe despite disagreement.

## The receipt that closes this incident

The PeopleSoft campaign is tempting to remember as a clever `%50` trick. That is the memorable detail, but it is not the durable lesson. Attackers change representations cheaply. Defenders close incidents by changing the state of the vulnerable system and proving the change.

A credible closure statement for CVE-2026-35273 can be short:

> We identified every PeopleSoft instance, installed and activated Oracle's repair or removed the affected component, searched edge, application, and host evidence back to the start of our exposure, revoked authority available to any affected service, and verified the result from outside the boundary.

Each clause needs an attached receipt. Inventory output supports “every instance.” Runtime version and restart evidence support “activated.” Preserved logs and host findings support “searched.” Rotation and revocation records support “revoked.” An external validation supports “verified.” If a clause lacks evidence, it remains work in progress.

The firewall still belongs in the design. It can reject known probes, constrain management traffic, and give responders time. It just should not be asked to certify code it cannot repair.

One encoded letter got through because two systems disagreed about a path. The way out is not a longer list of forbidden spellings. Patch the component, narrow the route, inspect the earlier window, and keep the receipt.

For one practical security email each month, subscribe to the newsletter on this site.

## Sources

- [Oracle: Security Alert Advisory for CVE-2026-35273](https://www.oracle.com/security-alerts/alert-cve-2026-35273.html), accessed 2026-09-27
- [Google Cloud: ShinyHunters Renewed Mass Exploitation Campaign Targeting Oracle PeopleSoft](https://cloud.google.com/blog/topics/threat-intelligence/shinyhunters-renewed-mass-exploitation-campaign-targeting-oracle-peoplesoft), accessed 2026-09-27
- [CISA: Known Exploited Vulnerabilities Catalog JSON feed](https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json), accessed 2026-09-27
- [BleepingComputer: ShinyHunters uses WAF bypass trick in Oracle PeopleSoft attacks](https://www.bleepingcomputer.com/news/security/shinyhunters-uses-waf-bypass-trick-in-oracle-peoplesoft-attacks/), accessed 2026-09-27
- [The Hacker News: Attackers Bypass WAFs to Exploit Oracle PeopleSoft Flaw and Deploy Web Shells](https://thehackernews.com/2026/09/attackers-bypass-wafs-to-exploit-oracle.html), accessed 2026-09-27
- [NIST: Incident Response Recommendations and Considerations for Cybersecurity Risk Management](https://csrc.nist.gov/pubs/sp/800/61/r3/final), accessed 2026-09-27

---

## About the author

Kubilay Tunca — Senior Full Stack Developer and Author. Founded Cyber Security in Plain English to translate complex security concepts into clear, practical advice, and writes the accompanying books on security, privacy, secure development, and AI systems.

## Books by this author

- **The Digital Fortress** — Your Everyday Guide to a Safer Digital Life. A warm, plain-English guide for people with real lives and finite patience. Learn the handful of habits that genuinely protect your money, accounts, and family, and get honest permission to ignore the rest. [Amazon](https://buy.cyber-security-in-plain-english.com/digital-fortress) · [Details](https://cyber-security-in-plain-english.com/books/the-digital-fortress)
- **The Anonymity Playbook** — Digital Survival for Whistleblowers, Journalists, Activists, and Everyone Else. A practitioner’s field manual for journalists protecting sources, whistleblowers, and activists. It explains how the surveillance actually works, what each technique costs you, and exactly where it fails. [Amazon](https://buy.cyber-security-in-plain-english.com/anonymity-playbook) · [Details](https://cyber-security-in-plain-english.com/books/the-anonymity-playbook)
- **Secure Software Development** — Practical patterns for building secure software. A hands-on security guide for developers and IT professionals who ship real software. Build, deploy, and maintain secure systems without slowing down or drowning in theory. [Amazon](https://buy.cyber-security-in-plain-english.com/secure-software-development) · [Details](https://cyber-security-in-plain-english.com/books/secure-software-development)
- **The Secure Harness** — Shipping Production Code with AI Coding Agents. A calm, practical guide to letting agents do useful work inside boundaries you set, enforce, and audit. Ships with 15 copy-pasteable artifacts: hook scripts, permission configs, release gates, and MCP templates. [Amazon](https://buy.cyber-security-in-plain-english.com/secure-harness) · [Details](https://cyber-security-in-plain-english.com/books/the-secure-harness)
- **The AI Native Engineer** — Build, Evaluate, and Ship AI Systems That Work in Production. Sixteen hands-on chapters, one real product. Grow it from a single model call into a retrieved, tool-using, observable, production-grade system, with evaluation treated as a habit from the first feature. [Amazon](https://buy.cyber-security-in-plain-english.com/ai-native-engineer) · [Details](https://cyber-security-in-plain-english.com/books/the-ai-native-engineer)

Full catalogue with contents and intended audience: https://cyber-security-in-plain-english.com/books

_As an Amazon Associate I earn from qualifying purchases. Buying through these links costs you nothing extra and helps pay for the blog._