Outdated DataTables Library Has a Known Security Flaw

Vulnerability Explanation

The vulnerability exists in the `_fnSetObjectDataFn` (also referred to as `setData`) function within `jquery.dataTables.js`. When the `columns.data` option is set to a value containing `__proto__`, the function fails to sanitise the key before assigning it to an object, allowing an attacker to inject properties directly onto `Object.prototype`. Because all JavaScript objects inherit from `Object.prototype`, a polluted prototype can silently alter the behaviour of any object in the application — including those used by other libraries running on the same page. An initial fix was shipped in 1.10.22, but it was incomplete; CVE-2020-28458 documents the bypass, which was fully resolved in 1.10.23.

Root Cause

The `_fnSetObjectDataFn` helper uses dot-notation string paths (e.g. `columns.data: 'user.name'`) to set nested object properties without validating or blocking reserved prototype keys such as `__proto__`, `constructor`, and `prototype`. This is a classic prototype pollution pattern (CWE-1321) caused by insufficient input sanitisation when performing dynamic property assignment.

Technical Impact

An attacker who can influence the value passed to `columns.data` — for example, via a URL parameter, API response, or user-supplied configuration — can pollute `Object.prototype`. Depending on how the application uses the affected objects, this can lead to: denial of service (application errors / crashes), unexpected code execution paths, or — in server-side Node.js contexts where DataTables is rendered — potential remote code execution. In a typical browser-only deployment the realistic impact is application logic manipulation and DoS.

Severity Justification

CVSS 7.3 (High) per the GitHub Advisory Database (CVE-2020-28458). Network-reachable, no authentication required, no user interaction needed. Impact is limited in scope (same security authority), with partial confidentiality, integrity, and availability impact — hence High rather than Critical.

Affected Components

• datatables.net < 1.10.23
• jquery.dataTables.js < 1.10.23

Remediation Steps

1. Upgrade DataTables to version 1.10.23 or later. Note: 1.10.22 contains only a partial fix — the bypass was addressed in 1.10.23. Prefer the current stable release (1.13.x or later).
2. If loading via npm/yarn: run `npm install datatables.net@latest` (or `yarn upgrade datatables.net`) and redeploy.
3. If loading via a CDN `<script>` tag, update the URL to point to 1.10.23+ (e.g. `https://cdn.datatables.net/1.13.8/js/jquery.dataTables.min.js`).
4. If using a bundled/vendored copy of `jquery.dataTables.js`, replace the file manually and verify the version string at the top of the file.
5. After upgrading, audit any usage of `columns.data` that accepts user-supplied or externally-sourced values, and ensure those values are validated against an allowlist before being passed to DataTables.

Verification Steps

1. Check the running version in the browser console: `$.fn.dataTable.version` — confirm it returns 1.10.23 or higher.
2. Inspect the page source or network tab to confirm the loaded DataTables script URL or bundle reflects the updated version.
3. Run `npm list datatables.net` (or `yarn list --pattern datatables.net`) in your project to confirm the installed version.
4. Run `npm audit` or `yarn audit` and verify no DataTables prototype pollution advisories are reported.

Code Examples (html)

<!-- Vulnerable: outdated CDN link -->
<script src="https://cdn.datatables.net/1.10.19/js/jquery.dataTables.min.js"></script>

<!-- Fixed: updated to a patched release -->
<script src="https://cdn.datatables.net/1.13.8/js/jquery.dataTables.min.js"></script>

<!-- Or, if using npm -->
<!-- Run: npm install datatables.net@latest -->

Best Practices

• Never pass unsanitised user input directly to `columns.data` or any DataTables configuration option that accepts dot-notation paths.
• Pin frontend library versions in your package.json and use `npm audit` or a dependency scanning tool (e.g. Snyk, Dependabot) in CI to catch vulnerable versions before they reach production.
• Prefer loading DataTables via a package manager over CDN links — package managers make version tracking and auditing significantly easier.
• When evaluating dot-notation property paths at runtime, validate keys against an allowlist and explicitly block `__proto__`, `constructor`, and `prototype`.

References

• security.snyk.io/vuln/SNYK-JS-DATATABLESNET-598806
• security.snyk.io/vuln/SNYK-JS-DATATABLESNET-1016402
• github.com/advisories/GHSA-m7j4-fhg6-xf5v
• cdn.datatables.net/1.10.22/