TL;DR: hardcoded ociforums.com support-fallback link inside Oracle settings-v2.js
- Live link, dead domain: Every enterprise thinks it retires vendor references cleanly, but Oracle shipped a live no-agents-available support link to ociforums.com from settings-v2.js while the domain sat expired and up for purchase.
- How cside caught it: cside spotted the ociforums.com reference from client-side behavioral observation, reported it, and Oracle credited us on the cpuoct2025 security advisory, exactly because CSP would have kept a hijacked owner on the allowlist and SRI does not protect an in-UI hyperlink that is not a hashed script dependency.
- Luck or monitoring: The link was hardcoded into JavaScript on every embed of the widget, so the decision is whether you keep discovering expired references in shipped code by luck or by continuous runtime behavioral monitoring of every domain you still call.
Short on time? See cside's in-browser Magecart and skimmer blocking. It covers everything below in one deployment.
At cside, we continuously monitor websites for anything suspicious so we can protect users before attacks happen. Recently, we spotted a case involving a well-known website: Oracle.
While reviewing one of Oracle's public JavaScript files we noticed it contained a link to a domain that has expired.
[https://www.oracle.com/asset/web/js/settings-v2.js](https://www.oracle.com/asset/web/js/settings-v2.js)
This blog looks at the risks of forgotten or expired domains in client-side code. This is not an old or rare problem, it can happen to both big and small companies, and it can easily open the door to a supply chain attack.
Note: Our team reported this finding to Oracle, who remediated it quickly. The purpose of this blog is to examine the security implications from a defensive standpoint. It should not be interpreted as guidance for exploitation or novel attack development
The expired domain in question
Some portions in this section are written in the present tense as they were taken directly from conversations with our security analyst.
The expired domain is:
ociforums.com
Visiting it now redirects to:
https://expireddomains.com/domain/ociforums.com
(screenshot was taken at the time of discovery, this has since been remediated).
Inside Oracle's JavaScript file, there's a reference to:
http://ccc.ociforums.com/
This link appears in the website code as part of a message shown to users when no live chat agents are available. Because the domain is expired and up for sale, anyone could purchase it and use it for malicious purposes.
Why this expired domain was a security risk
Here's the exact snippet from the file:
ocFeedback: {
en: "Sorry, no agents are available... post your question at <a href='http://ccc.ociforums.com/'>http://ccc.ociforums.com/</a>..."
}
This message is shown to users who are already looking for help. They are more likely to trust the link as a legitimate Oracle support page. If an attacker bought the domain, several risks could follow:
- Phishing: the attacker could create a fake forum that looks like Oracle's and trick users into sharing their account credentials.
- Malware hosting: the domain could deliver malicious downloads or run exploit kits.
- SEO abuse: because the domain might still have good search rankings, it could show up in searches for Oracle support and lead people to the fake site.
- Brand damage: if users are tricked, they may blame Oracle and lose trust in the brand.
Long-term risk: the link is hardcoded into the JavaScript, meaning every site using this widget would need an update. If not patched quickly, the exposure lasts.
Example attack scenario
- A user tries to get Oracle support but no agents are available.
- The message tells them to visit ccc.ociforums.com.
- The domain is now owned by an attacker.
- The user clicks and is asked to log in with their Oracle credentials.
- The attacker collects the credentials and can also deliver malware or launch other scams.
What the cside team did
We reached out to Oracle and informed them about the expired domain issue. They proceeded very quickly to purchase the domain back and gave us credit on their security reporting programs. We applaud Oracle for their fast response.
This situation shows how website complexity and exposure over time can become a challenge even for organizations that are well prepared for security incidents. Client-side security is an often overlooked space, and that applies to businesses of all sizes.
What could have prevented an expired domain attack?
If we played out the scenario where an attacker did get access to this domain: CSP and SRI would have both missed this.
CSP and SRI would fail
CSP (Content Security Policy) and SRI (Sub Resource Integrity) are commonly used client-side defense mechanisms. CSP validates where requests originate, not whether the destination is still safe. The browser will allow the request regardless of who owns the domain now. SRI ensures file integrity only when the developer controls the resource. In this case, the reference was a hyperlink rendered inside the UI, not an external script dependency protected by a hash.
Client-side security catches signs of an expired domain attack
A client-side security platform such as cside continuously observes how scripts behave at runtime. If a domain suddenly starts issuing redirects, collecting key strokes, serving unexpected JavaScript, or returning unusual response patterns, the shift in behavior becomes an immediate red flag, and cside would trigger an alert for security teams to inspect.
