CVE-2019-10768 is a prototype pollution vulnerability in AngularJS before version 1.7.9, in which the merge() utility can be manipulated with a __proto__ payload to add or modify properties on Object.prototype, affecting every object in the running application. It carries a CVSS 3.x base score of 7.5 (High), with impact concentrated on integrity, and it can be triggered remotely without authentication. If your application still ships the legacy AngularJS framework, this is one to check for.
This post explains what prototype pollution is, why the merge() function was vulnerable, and the practical steps to find and fix it. All version and scoring details below are drawn from the published advisory and the National Vulnerability Database.
What prototype pollution is
In JavaScript, almost every object inherits from Object.prototype. If an attacker can write a property onto Object.prototype itself, that property suddenly appears on every object in the program that does not explicitly override it. This is prototype pollution: corrupting the shared base object so that unrelated code reads attacker-controlled values.
The magic keys that make this possible are __proto__, constructor, and prototype. A function that merges attacker-supplied data into an object, without filtering those keys, walks straight into the trap. Depending on what the application does downstream, the consequences range from denial of service and logic corruption to, in some setups, escalation toward code execution.
Why AngularJS merge() was vulnerable
AngularJS shipped a merge() helper that recursively combined the properties of source objects into a target. The flaw in CVE-2019-10768 is that this recursion did not exclude the dangerous keys. When one of the source objects contained a __proto__ property, merge would follow it and write into Object.prototype rather than treating it as an ordinary own property.
Conceptually, the dangerous input looks like this:
// illustrative payload shape, not an exploit against a live target
var malicious = JSON.parse('{"__proto__": {"polluted": "yes"}}');
angular.merge({}, malicious);
// after the merge, an unrelated fresh object inherits the property:
var innocent = {};
console.log(innocent.polluted); // "yes"
Any code path where user-controlled JSON reached merge() was a candidate for exploitation. That made the practical risk depend heavily on how a given application used the function, which is a common trait of prototype pollution bugs: the framework flaw is real, but reachability determines how bad it is for you.
Affected versions and the fix
The advisory records AngularJS as vulnerable from 1.4.0-beta.6 up to, but not including, 1.7.9. Upgrading to AngularJS 1.7.9 remediates the issue; the patched merge() rejects the dangerous keys instead of following them.
The complication in 2025 and beyond is that AngularJS (the 1.x line) reached end of life and is no longer maintained by Google. So while 1.7.9 fixes this specific CVE, staying on AngularJS at all means accepting a framework that receives no further security patches from upstream. That is a strategic consideration, not just a patch-level one.
How to find it in your codebase
Prototype pollution in a transitive dependency is easy to miss because you may not have added AngularJS directly. Check in two places.
First, your lockfile. Search package-lock.json or yarn.lock for angular and confirm the resolved version. If it is below 1.7.9 and in the affected range, you are exposed.
# quick check across a monorepo
grep -rn '"angular"' --include=package-lock.json .
npm ls angular
Second, vendored copies. Plenty of older projects committed angular.min.js straight into a static directory, bypassing the package manager entirely. A lockfile scan will not catch those; a file-level scan or grep for the version banner in the bundled file will. An SCA scanner that inspects both declared dependencies and vendored files, such as Safeguard, can flag CVE-2019-10768 even when the vulnerable copy was checked in by hand rather than installed.
Remediation options
If you can upgrade, move to AngularJS 1.7.9 or later within the 1.x line to close this specific flaw. If you cannot upgrade immediately, reduce reachability: audit every call to angular.merge() and ensure attacker-controlled JSON never flows into it unsanitized. Reject or strip __proto__, constructor, and prototype keys at your input boundary as a defense-in-depth measure that helps against prototype pollution generally, not just this CVE.
The durable fix is migrating off AngularJS entirely, since the framework is no longer maintained. That is a larger project, but any long-lived application still on AngularJS is accumulating unpatched risk beyond this one advisory.
Broader lessons on prototype pollution
CVE-2019-10768 is one instance of a class that has hit many JavaScript libraries: merge, extend, clone, and set-by-path utilities that fail to guard the prototype keys. The defensive patterns generalize. Prefer Object.create(null) for maps that hold untrusted keys, use Map instead of plain objects for user-controlled dictionaries, and validate input against a schema before merging. Keeping dependencies current is the single most effective control, because these bugs are found and patched regularly, and the fix usually ships as a minor version bump.
FAQ
What is the CVSS score of CVE-2019-10768?
It has a CVSS 3.x base score of 7.5, rated High. The impact is on integrity, with the attack exploitable remotely and without authentication.
Which AngularJS versions are affected by CVE-2019-10768?
AngularJS from 1.4.0-beta.6 up to but not including 1.7.9. Upgrading to 1.7.9 or later within the 1.x line remediates this specific vulnerability.
Is this the same as Angular (2+)?
No. CVE-2019-10768 affects the legacy AngularJS 1.x framework, not the modern Angular (versions 2 and above), which is a separate rewrite with a different codebase.
Can prototype pollution lead to remote code execution?
By itself it corrupts object state, but in applications that later use polluted properties in sensitive operations it can escalate. The realistic impact depends on how the application uses the polluted objects downstream, which is why reachability analysis matters.