Outdated DataTables Library Has a Known Script Injection Flaw

Vulnerability Explanation

The DataTables library's internal `htmlEscapeEntities()` function failed to handle array-type inputs correctly. When a JavaScript array was passed to this function instead of a string, the function would skip HTML escaping entirely and render the raw array contents into the DOM. An attacker who can control data fed into a DataTable (e.g. via a stored record, API response, or URL parameter) can craft an array value containing an HTML payload such as `<img src=x onerror=alert(1)>`, which will execute in the victim's browser without sanitisation.

Root Cause

The `htmlEscapeEntities()` function assumed its input would always be a string and performed no type-checking. JavaScript's implicit array-to-string coercion (`Array.prototype.toString()`) bypassed the escaping logic, allowing raw HTML to pass through to the DOM. The fix was a one-line guard: check `Array.isArray()` before escaping, and convert array elements individually.

Technical Impact

Successful exploitation allows an attacker to execute arbitrary JavaScript in the context of the victim's browser session. Realistic outcomes include session token theft (cookie hijacking), UI redressing (fake login prompts), forced actions on behalf of the authenticated user, and — in admin-facing tables — potential privilege escalation within the application. Exploitation requires the attacker to control data that is rendered by a DataTable, which limits the attack surface to applications that display user-supplied or externally sourced content in tables.

Severity Justification

CVSS 3.1 vector AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N yields a score in the 6.1 range. User interaction is required (victim must load the page), and impact is limited to partial confidentiality and integrity. No public exploit code is actively weaponised, and the EPSS score is approximately 0.14%, indicating low real-world exploitation activity.

Affected Components

• datatables.net < 1.11.3
• org.webjars.bower:datatables.net < 1.11.3
• org.webjars.npm:datatables.net < 1.11.3

Remediation Steps

1. Upgrade `datatables.net` to version 1.11.3 or later via your package manager: `npm install datatables.net@latest` or `yarn add datatables.net@latest`. Verify the installed version in `package.json` and `package-lock.json`.
2. If DataTables is loaded via a CDN `<script>` tag rather than npm, update the URL to point to version 1.11.3 or later (e.g. `https://cdn.datatables.net/1.11.3/js/jquery.dataTables.min.js`).
3. Audit your dependency tree for transitive or bundled copies of DataTables: run `npm ls datatables.net` (or equivalent) to identify all instances, including those pulled in by plugins such as `datatables.net-bs4`, `datatables.net-buttons`, etc. Each plugin has a corresponding updated release — upgrade them in tandem.
4. Ensure any user-supplied data rendered in DataTables is also escaped server-side before being sent to the client. Do not rely solely on client-side escaping as a security control.
5. Add a Content Security Policy (CSP) header to your application as a defence-in-depth measure. A `script-src` directive that restricts inline scripts will significantly limit the impact of any future XSS vulnerabilities.

Verification Steps

1. After upgrading, run `npm ls datatables.net` and confirm all resolved versions are 1.11.3 or higher.
2. Open your browser's DevTools, load a page with a DataTable, and check the loaded script URL or the `$.fn.dataTable.version` property in the console — it should return `1.11.3` or later.
3. Test the fix by passing an array value into a DataTable column and confirming it is rendered as escaped text, not as HTML. For example, set a cell value to `['<img src=x onerror=alert(1)>']` and verify no alert fires.
4. Run your existing test suite to confirm no regressions in table rendering behaviour, particularly for columns using custom `render` functions.

Code Examples (html)

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

<!-- Array values passed to DataTables are NOT escaped -->
<script>
  $('#example').DataTable({
    data: [
      { name: ['<img src=x onerror=alert(1)>'] }  // XSS payload executes
    ],
    columns: [{ data: 'name', render: $.fn.dataTable.render.text() }]
  });
</script>

<!-- Fixed: DataTables 1.11.3+ loaded from CDN -->
<script src="https://cdn.datatables.net/1.11.3/js/jquery.dataTables.min.js"></script>

<!-- Array values are now correctly escaped before rendering -->
<script>
  $('#example').DataTable({
    data: [
      { name: ['<img src=x onerror=alert(1)>'] }  // Rendered as escaped text
    ],
    columns: [{ data: 'name', render: $.fn.dataTable.render.text() }]
  });
</script>

<!-- Or via npm -->
// package.json
// "datatables.net": "^1.11.3"

Best Practices

• Pin front-end library versions in `package.json` and use a lockfile (`package-lock.json` / `yarn.lock`) to prevent silent upgrades or downgrades.
• Integrate a software composition analysis (SCA) tool (e.g. `npm audit`, Snyk, or Dependabot) into your CI pipeline to automatically flag vulnerable dependencies on every pull request.
• Never rely solely on client-side escaping — always sanitise and validate user input on the server before storing or returning it.
• Implement a Content Security Policy with a restrictive `script-src` directive to reduce the blast radius of any XSS vulnerabilities that slip through.

References

• security.snyk.io/vuln/SNYK-JS-DATATABLESNET-1540544
• nvd.nist.gov/vuln/detail/CVE-2021-23445
• github.com/DataTables/Dist-DataTables/commit/59a8d3f8a3c1138ab08704e783bc52bfe88d7c9b
• cdn.datatables.net/1.11.3/