AT&T Authentication Bypass and Remote Code Execution: A Three-Year-Old CVE, Still Reachable
V-Spot identified an authentication bypass on AT&T's internet-exposed WebLogic Server 10.3.6.0 that resolved to Oracle CVE-2020-14882, a widely-exploited path traversal in the WebLogic console. Three years after the original CVE disclosure, the console was reachable, the bypass worked, and the path to remote code execution ran through it. This is V-Spot's writeup of the finding and the wider lesson on legacy-infrastructure patch discipline in Fortune 100 telecommunications.
During a routine external attack surface review, V-Spot's research division identified an authentication bypass on an internet-facing AT&T server management interface. The affected endpoint exposed Oracle WebLogic Server version 10.3.6.0, on which the URL pattern /console/images/%252E%252E%252Fconsole.portal?_nfpb=true&_pageLabel=HomePage1 bypassed the authentication filter and delivered the WebLogic Server Administration Console to an unauthenticated visitor. From there, standard WLST-based remote code execution primitives applied.
The bypass itself is not novel. It resolves to Oracle CVE-2020-14882, a path-traversal authentication bypass in the WebLogic console first disclosed on 21 October 2020 and included in the initial launch of CISA's Known Exploited Vulnerabilities catalogue in November 2021. The novelty of this finding, and the reason it is worth writing up, is that a three-year-old CVE on a widely-scanned product was still reachable on production AT&T infrastructure in mid-2023. This is V-Spot's writeup of the technical finding, and the wider lesson on how legacy-infrastructure patch discipline fails inside organisations that have every resource to prevent it.
The bypass
The vulnerable request looks unremarkable. It targets a static-asset path (/console/images/) that the WebLogic authentication filter treats as unauthenticated content. The double-URL-encoded traversal (%252E%252E%252F, which decodes once to %2E%2E%2F and then again to ../) redirects the request out of the images directory and into the console proper. The filter has already made its authentication decision before the second decode occurs, so the authenticated console page is served to a request the filter believed was for an unauthenticated static asset.
Once the console renders, the administration panel is fully navigable. WebLogic does not re-authenticate on per-tab basis inside the console; the traversal has crossed the trust boundary once, and every subsequent navigation inherits that state. The only trivial change required to move between console tabs is to swap http for https in the copied panel URLs, a workaround for a mixed-content quirk in this specific deployment.
From the console, remote code execution is a documented primitive. WebLogic's WLST scripting engine and the WLS-WSAT deserialisation gadget chain (CVE-2017-10271, still bundled in 10.3.6.0) provide multiple published paths to arbitrary code execution on the underlying host. V-Spot did not exploit the RCE primitive against AT&T infrastructure; the authentication bypass alone is sufficient to demonstrate the impact for responsible disclosure purposes.
The class of problem
The technical finding is a specific CVE. The interesting question is why the CVE was still reachable three years after its disclosure on an asset belonging to one of the largest telecommunications companies in the world.
Three factors are usually present when this pattern appears in a Fortune 100 environment. The first is scope drift in attack surface inventory. Large enterprises maintain nominal inventories of their internet-exposed assets, but the inventory typically covers assets that infrastructure teams provisioned deliberately. Legacy management interfaces attached to acquired product lines, decommissioned business units, and shadow-IT deployments from earlier decades sit outside the inventory that current security teams monitor. They are exposed. Nothing in the current asset-management tooling knows to check them.
The second factor is that WebLogic 10.3.6.0 was out of Premier Support from 2018 and out of Extended Support entirely by 2021. Systems still running that version in 2023 are almost always in one of two categories. Either the underlying application depends on WebLogic-specific behaviour that a newer version would break, and the team responsible has been unable to schedule the migration. Or the system is orphaned, the responsible team no longer exists, and the box has been running unattended for years.
The third factor is that CVE-2020-14882 has excellent public exploitation tooling. Every widely-used vulnerability scanner detects it. Every attacker-orientated toolkit exploits it. If the AT&T asset was ever visible to the internet with unfiltered access to /console, it is statistically likely that it has been probed for CVE-2020-14882 many times over the three years since the CVE was published. The V-Spot finding is the case where a friendly researcher documented the exposure. The unfriendly cases likely occurred first.
The impact
The direct impact of the specific finding is straightforward. An unauthenticated attacker who reaches the AT&T-hosted WebLogic console can inspect and modify server configuration, deploy arbitrary applications, extract deployment descriptors, read configuration files including database credentials stored in cleartext or reversibly-encrypted form, and pivot to remote code execution on the underlying host through documented WebLogic RCE gadget chains. On a management interface deployed inside a telecommunications environment, the pivot from RCE to broader network access is typically short.
The indirect impact is the one worth internalising. An organisation that has a three-year-old CVE on an internet-exposed console has, by inference, a broader attack surface management gap. The specific asset V-Spot identified is a lagging indicator. The condition that produced it is the leading indicator. There will be other assets in the same category. Some of them will be running versions of software with newer CVEs. Some of them will be in the middle of active exploitation by parties less inclined to file responsible disclosure reports.
What the finding says about the class
Three lessons apply broadly to any organisation that operates infrastructure at telecommunications scale.
Continuous attack surface enumeration is not a project, it is a service. Point-in-time asset inventories degrade quickly. Assets get added by teams that do not report through the security function. Assets get inherited through acquisitions. Assets get orphaned when teams reorganise. An asset inventory maintained through periodic reviews will always lag reality. The gap between the inventory and reality is where CVE-2020-14882-class findings live.
End-of-support versions are the first place to look. Any Oracle WebLogic 10.3.x, any Windows Server 2008/2012, any RHEL 6, any Confluence pre-8, any Exchange pre-2019. These are not obscure targets. Every offensive toolkit knows what CVEs apply to them. Every attacker with time to invest is aware of the yield. Any exposure of these products to the internet is, in practice, a matter of when rather than whether.
A management interface reachable from the internet is a design decision, and it is almost always the wrong one. WebLogic Server Administration Console, VMware vCenter, Fortinet FortiManager, Cisco DNA Center, and their equivalents in every enterprise stack. These interfaces exist to serve internal operations teams. They do not need to be reachable from anywhere except the internal management network. When they are internet-reachable it is because a firewall rule was added years ago to solve a short-term operational problem and never removed. Removing those rules retrospectively is one of the highest-yield attack-surface reduction moves an organisation can make.
Seven concrete moves for teams operating WebLogic in production
If your environment includes WebLogic anywhere, the moves below are the ones V-Spot researchers would prioritise:
1. Identify every WebLogic instance across your fleet, including test, staging, disaster-recovery, and acquired-company deployments. Version, patch level, and network exposure.
2. For every internet-reachable instance, confirm the exposure is deliberate. If it is not deliberate, remove the firewall rule that permits it. If it is deliberate, document why.
3. Verify every deliberately-exposed instance is on a supported version with the latest quarterly Critical Patch Update applied. WebLogic 10.3.x is unsupported. Any 10.3.x instance internet-exposed is in scope for immediate migration or immediate isolation.
4. Apply the CVE-2020-14882 remediation specifically. Oracle's fix removes the path-traversal decoding vulnerability, but the mitigation of restricting /console access by network policy is faster to deploy and does not require an application-server restart.
5. Add WebLogic-specific detection to your web application firewall. URL patterns matching %252E%252E%252F and other double-encoded traversals reaching /console/ routes are near-certain exploitation attempts.
6. Rotate the credentials stored in WebLogic configuration files as a routine. Historical WebLogic RCE bugs have consistently exposed these credentials, and their rotation cadence in most environments is far too slow relative to the actual exposure.
7. Set an internal SLA on removing internet-reachable management interfaces. A management interface that is reachable from an untrusted network is a compounding risk. The right SLA in most environments is measured in weeks after discovery, not months.
The V-Spot lens
Every organisation running production infrastructure at scale has assets it has forgotten about. Every internet-exposed WebLogic 10.3.x instance was, at some point, deliberately configured that way by someone who understood the trade-offs at the time and expected the exposure to be short-lived. The trade-offs changed. The person moved teams. The instance remained.
The technical bypass in this finding is public knowledge. The exposure of a specific AT&T asset to that bypass in mid-2023 is the reportable finding. The wider claim, which V-Spot's research division stands behind, is that this specific finding is the visible tip of a broad attack-surface management gap that exists inside almost every organisation of comparable size. Finding one such asset takes minutes. Finding the second, third, and fourth asset takes hours. Fixing the class of problem takes attack-surface enumeration discipline, patch programme investment, and a firewall-rule review cadence that most enterprises do not currently maintain.
If you are running WebLogic, or operating an enterprise attack surface at telecommunications scale, V-Spot's research division and offensive security team can help. We run attack-surface reviews of exactly this class for our clients, and we would rather your version of this writeup came from us than from someone with no interest in filing responsible disclosure.