5 Ways to Prove Your PeopleSoft Internet-Facing Footprint Is Actually Closed
Practical PeopleSoft, every Thursday | Published on PeopleSoftCloud.com
Every shop I talk to says the same thing about CVE-2026-35273: we patched it.
Good. Patching was the easy part. The uncomfortable part is that the vulnerability was only interesting because those endpoints were reachable from the internet in the first place — and patching doesn’t change that. /PSEMHUB/hub and /PSIGW/HttpListeningConnector are still exposed in most environments I’ve seen, still answering requests from anyone who asks.
“We patched it” is a claim. Here are five ways to turn it into evidence.
1. Enumerate from the outside, not from the inside
Your network diagram is not evidence. It describes intent, not reality — and it was accurate the day it was drawn.
Censys counted roughly 40 internet-facing PeopleSoft hosts worldwide during the exploitation window, and called that a conservative estimate. Separately, IPinfo surfaced 24 live PeopleSoft instances across 16 organizations from a single day of scraped web data — without sending a single packet at any target.
🔗 Finding exposed PeopleSoft instances using web scrape data (IPinfo) https://community.ipinfo.io/t/finding-exposed-peoplesoft-instances-using-ipinfos-web-scrape-data/7376
That’s the test that counts: can a stranger find you without trying? Get an external view of your own perimeter — a scan from a cloud host, a Censys or Shodan query on your domains and ASN — and compare it to what you believe is published. The gap is your actual attack surface.
2. Curl the two paths from a network you don’t control
Not from the DMZ. Not from the VPN. From a coffee shop, or a $5 VM.
Request /PSEMHUB/hub and /PSIGW/HttpListeningConnector on every PIA URL you own — prod, test, dev, and the one somebody stood up for a 2019 project and never decommissioned. A connection refused or a perimeter-level block is a pass. An HTTP response of any kind is a finding, including a 401 or a 404.
Rapid7 is specific on this point, and it matters: block these at the network perimeter, not with WAF body-inspection rules alone.
🔗 Active Exploitation of the Oracle PeopleSoft Zero-Day (Rapid7) https://www.rapid7.com/blog/post/etr-active-exploitation-of-oracle-peoplesoft-zero-day-cve-2026-35273/
3. Decide whether EMHub should exist at all
Most sites do not need the Environment Management Hub running, and almost none need it published. The guidance from multiple responders converged: disable the EMHub service in multi-server configurations, or remove the PSEMHUB application entirely in single-server deployments.
🔗 Defending Against the PSEMHUB Authentication Bypass (Qualys ThreatPROTECT) https://threatprotect.qualys.com/2026/06/18/cve-2026-35273-defending-against-the-oracle-peoplesoft-psemhub-authentication-bypass/
There is a real cost — you lose Change Assistant’s environment discovery — and you should decide that deliberately rather than leave it running because nobody asked.
4. Check egress, not just ingress
The RCE got them in. Outbound SMB on TCP/445 is what let them harvest machine-account NetNTLM hashes and move.
Almost nobody audits this. Your PeopleSoft web and app tiers should not be able to open arbitrary outbound connections to the internet. Verify that from the host, not from the firewall policy — try it and watch it fail.
5. Know what your login page volunteers
Attackers pick targets by fingerprint. Sign-in pages leak PeopleTools version, server names, and full internal hostnames in redirects and error pages. And one rule worth writing on the wall: PeopleSoftListeningConnector should never be the target of an external integration — that’s what HttpListeningConnector behind a proxy is for.
🔗 PeopleSoft Online Security (Oracle docs) https://docs.oracle.com/cd/F70249_01/pt860pbr1/eng/pt/tsec/PeopleSoftOnlineSecurity-c0765d.html
Do this once, then make it repeatable
CISA added CVE-2026-35273 to the KEV catalog on June 12 with a remediation deadline of June 15 — three days. That is the tempo now, and you will not meet it by starting from scratch each time.
So produce an artifact: a dated list of every PeopleSoft URL you own, what each one exposes externally, and who signed off. Re-run it quarterly. When the next 9.8 lands — and it will — the question won’t be “are we patched?” It’ll be “what’s reachable?” You should already have that answer written down.
Next Thursday: why your patch cycle is slower than your attackers, and the four handoffs where the time actually goes.
🌐 Join the Community
Subscribe at www.peoplesoftcloud.com for weekly PeopleSoft, ERP, and cloud platform guidance — the Monday Digest for what happened, Thursdays for what to do about it.



