CVE-2026-11998
This Vulnerability has been fixed in the Never-Ending Support (NES) version offered by HeroDevs.
Overview
AngularJS is a JavaScript framework for developing dynamic web applications. It lets you use HTML as your template language and lets you extend HTML's syntax to express your application's components clearly and succinctly.
A Cross-Site Scripting (XSS) vulnerability (CVE-2026-11998) has been identified in AngularJS’ Strict Contextual Escaping (SCE) service, which allows attackers to bypass SCE policies for resource URLs and can lead to arbitrary JavaScript execution within the context of the victim's browser session.
Per OWASP: Cross-Site Scripting attacks are a type of injection, in which malicious scripts are injected into otherwise benign and trusted websites. XSS attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser side script, to a different end user. An attacker can use XSS to send a malicious script to an unsuspecting user. The end user’s browser has no way to know that the script should not be trusted, and will execute the script. Because it thinks the script came from a trusted source, the malicious script can access any cookies, session tokens, or other sensitive information retained by the browser and used with that site. These scripts can even rewrite the content of the HTML page.
This issue affects versions of AngularJS greater than or equal to v1.2.0-rc.3.
Details
Module Info
- Product: AngularJS
- Affected packages: angular
- Affected versions: >=1.2.0-rc.3
- GitHub repository: https://github.com/angular/angular.js
- Published packages: https://www.npmjs.com/package/angular
- Package manager: npm
- Fixed in: AngularJS NES v1.9.12, v1.5.29 and v1.4.17
Vulnerability Info
This High-severity vulnerability is found in the angular package in AngularJS versions greater than or equal to v1.2.0-rc.3.
AngularJS uses the Strict Contextual Escaping (SCE) mode (via its $sce and $sceDelegate services) to only render trusted or safe values for certain security-sensitive contexts. One of these contexts is resource URLs, such as those used to load JavaScript scripts, <iframe> documents, route templates, etc. To designate certain URLs as safe resource URLs, you can specify a list of URL matchers using the trustedResourceUrlList() method, also known as resourceUrlWhitelist() in older versions. Each matcher can be either a string (with some wildcards) or a regular expression, which is supposed to be “matched against the entire normalized / absolute URL of the resource being tested (even when the RegExp did not have the ^ and $ codes)”, according to the AngularJS documentation.
However, due to a flaw in the logic that tries to apply the regular expression to the entire URL, certain regular expressions may be partially applied. As a result, unsafe resource URL values will fail to be blocked, potentially leading to Cross-Site Scripting (XSS).
Steps To Reproduce
- Create an AngularJS application that uses the ngSanitize module. For example:
angular.module('app', []);
- Use the $sceDelegateProvider#trustedResourceUrlList() method with a regular expression matcher that contains alternation. For example:
angular
.module('app')
.config($sceDelegateProvider => {
$sceDelegateProvider.trustedResourceUrlList([
/https:\/\/better\.com\/.*|https:\/\/good\.com\/.*/,
]);
});
- Try explicitly checking if a specially crafted malicious URL can be trusted as a resource URL. For example:
angular
.module('app')
.run($sce => {
$sce.getTrustedResourceUrl(
'https://evil.com/scripts.js#https://good.com/',
// Or...
// 'data:text/javascript,alert("HAX")//https://good.com/',
);
});
- Alternatively, you can verify that a malicious URL can be implicitly trusted and used as a resource URL by binding it to a RESOURCE_URL SCE context. For example:
<script ng-src="{{ maliciousUrl }}"><script>
Proof Of Concept
A full reproduction with code similar to the above can be found here:
Mitigation
The AngularJS project was already End-of-Life when this CVE was published and will not receive any updates to address this issue. For more information see the End-of-Life announcement.
Users of the affected components should apply one of the following mitigations:
- Migrate affected applications away from AngularJS.
- Leverage a commercial support partner like HeroDevs for post-EOL security support.
Credits
- George Kalpakas from HeroDevs (finder)