# CVE-2020-15092: Stored XSS in TimelineJS3

> Attackers can inject malicious scripts via crafted timeline data, leading to code execution in victim browsers.

- **Severity:** High 7.2 (`CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H`)
- **Exploited in the wild:** Not known
- **Login needed:** An administrator
- **Attackable:** Over the internet
- **Victim action needed:** Not needed
- **Fix available:** Yes
- **Published:** 9 Jul 2020
- **Updated:** 4 Aug 2024
- **Also known as:** GHSA-2jpm-827p-j44g

## What is CVE-2020-15092?

CVE-2020-15092 is a high-severity cross-site scripting vulnerability in NUKnightLab TimelineJS3, published on 9 Jul 2020. An attacker needs administrator access to exploit it, with no action from the victim.

### Official description

In TimelineJS before version 3.7.0, some user data renders as HTML. An attacker could implement an XSS exploit with maliciously crafted content in a number of data fields. This risk is present whether the source data for the timeline is stored on Google Sheets or in a JSON configuration file. Most TimelineJS users configure their timeline with a Google Sheets document. Those users are exposed to this vulnerability if they grant write access to the document to a malicious inside attacker, if the access of a trusted user is compromised, or if they grant public write access to the document. Some TimelineJS users configure their timeline with a JSON document. Those users are exposed to this vulnerability if they grant write access to the document to a malicious inside attacker, if the access of a trusted user is compromised, or if write access to the system hosting that document is otherwise compromised. Version 3.7.0 of TimelineJS addresses this in two ways. For content which is intended to support limited HTML markup for styling and linking, that content is "sanitized" before being added to the DOM. For content intended for simple text display, all markup is stripped. Very few users of TimelineJS actually install the TimelineJS code on their server. Most users publish a timeline using a URL hosted on systems we control. The fix for this issue is published to our system such that **those users will automatically begin using the new code**. The only exception would be users who have deliberately edited the embed URL to "pin" their timeline to an earlier version of the code. Some users of TimelineJS use it as a part of a wordpress plugin (knight-lab-timelinejs). Version 3.7.0.0 of that plugin and newer integrate the updated code. Users are encouraged to update the plugin rather than manually update the embedded version of TimelineJS.

Weakness: CWE-79 (Improper Neutralization of Input During Web Page Generation)

## Which versions are affected by CVE-2020-15092?

2 open source packages ship an affected version, including @knight-lab/timelinejs. It affects 1 product.


| Package | Ecosystem | Affected | Fixed in |
| --- | --- | --- | --- |
| `@knight-lab/timelinejs` | npm | All versions | 3.7.0 |
| `@knight-lab/timelinejs` | npm | All versions | 3.7.0 |

Products: Northwestern Timelinejs.

## How do I fix CVE-2020-15092?

Upgrade @knight-lab/timelinejs to 3.7.0 or later.

## Is CVE-2020-15092 being exploited?

There is no known exploitation of CVE-2020-15092 in the wild and no public exploit code.

## Fix prompt for AI coding agents

```text
Check this codebase for CVE-2020-15092 and fix it if it is affected.

What it is: CVE-2020-15092 is a high-severity cross-site scripting vulnerability in NUKnightLab TimelineJS3, published on 9 Jul 2020. An attacker needs administrator access to exploit it, with no action from the victim.
Exploitation: There is no known exploitation of CVE-2020-15092 in the wild and no public exploit code.

Affected packages and fixed versions:
- @knight-lab/timelinejs (npm): affected all versions; fixed in 3.7.0
- @knight-lab/timelinejs (npm): affected all versions; fixed in 3.7.0

Task:
1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.
2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.
3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.
4. Run the tests and summarise what changed and why.
5. If nothing in the project is affected, say so and change nothing.

Reference: https://insights.sbomify.com/CVE-2020-15092/ (Markdown: https://insights.sbomify.com/CVE-2020-15092/index.md)
```

## Sources

- CVE record: https://www.cve.org/CVERecord?id=CVE-2020-15092
- NVD: https://nvd.nist.gov/vuln/detail/CVE-2020-15092
- OSV: https://osv.dev/vulnerability/CVE-2020-15092

---
From sbomify Insights: https://insights.sbomify.com/CVE-2020-15092/
Summaries are generated and may contain mistakes; the official description above is the record.