# GHSA-vpr3-cw3h-prw8: SimpleSAMLphp Reflected Cross-site Scripting vulnerability

> Attackers can execute arbitrary JavaScript in user browsers via malicious SAML metadata endpoints, potentially leading to session hijacking or account takeover.

- **Severity:** Not scored
- **Exploited in the wild:** Not known
- **Login needed:** Not needed
- **Attackable:** Over the internet
- **Victim action needed:** A user has to click or open something
- **Fix available:** Yes
- **Published:** 28 May 2024

## What is GHSA-vpr3-cw3h-prw8?

GHSA-vpr3-cw3h-prw8 is a cross-site scripting vulnerability in simplesamlphp/simplesamlphp, published on 28 May 2024. An attacker can exploit it over the internet without logging in, and only if a user opens a file or follows a link.

### Official description

### Background
SimpleSAMLphp uses metadata to determine how to interact with other SAML entities. This metadata includes what’s called endpoints, which are URLs belonging to that entity where SAML messages can be sent. These URLs are used directly by SimpleSAMLphp when a message is sent, either via an HTTP redirection or by automatically posting a form to them.

### Description
When sending a SAML message to another entity, SimpleSAMLphp will use the URL of the appropriate endpoint to redirect the user’s browser to it, or craft a form that will be automatically posted to it, depending on the SAML binding used. The URL that’s target of the message is fetched from the stored metadata for the given entity, and that metadata is trusted as correct.

However, if that metadata has been altered by a malicious party (either an attacker or a rogue administrator) to substitute the URLs of the endpoints with javascript code, SimpleSAMLphp was blindly using them without any validation, trusting the contents of the metadata. This would lead to a reflected XSS where the javascript code is sent inline to the web browser, and if SimpleSAMLphp is not using a strict Content Security Policy to forbid inline javascript (which is the case of the default user interface), then the code will be executed in the end user’s browser.

### Affected versions
All SimpleSAMLphp versions are affected, up to 1.17.2.

### Impact
If metadata is consumed for a rogue entity that includes javascript code in the corresponding endpoints, this javascript code might be run by users trying to access this entity.

Even though it’s unlikely that an administrator would add metadata for an entity that contains such endpoints inadvertently, if metadata is consumed automatically (e.g. using metarefresh) it would be easier to have an scenario like the one described here if a SAML entity is compromised and its metadata modified.

The severity is assessed as medium given the difficulty to exploit the issue.

## Which versions are affected by GHSA-vpr3-cw3h-prw8?

2 open source packages ship an affected version, including simplesamlphp/simplesamlphp.


| Package | Ecosystem | Affected | Fixed in |
| --- | --- | --- | --- |
| `simplesamlphp/simplesamlphp` | Packagist | From 1.12.0 | 1.17.3 |
| `simplesamlphp/simplesamlphp` | Packagist | From 1.12.0 | 1.17.3 |

## How do I fix GHSA-vpr3-cw3h-prw8?

Upgrade simplesamlphp/simplesamlphp to 1.17.3 or later.

## Is GHSA-vpr3-cw3h-prw8 being exploited?

There is no known exploitation of GHSA-vpr3-cw3h-prw8 in the wild and no public exploit code.

## Fix prompt for AI coding agents

```text
Check this codebase for GHSA-vpr3-cw3h-prw8 and fix it if it is affected.

What it is: GHSA-vpr3-cw3h-prw8 is a cross-site scripting vulnerability in simplesamlphp/simplesamlphp, published on 28 May 2024. An attacker can exploit it over the internet without logging in, and only if a user opens a file or follows a link.
Exploitation: There is no known exploitation of GHSA-vpr3-cw3h-prw8 in the wild and no public exploit code.

Affected packages and fixed versions:
- simplesamlphp/simplesamlphp (Packagist): affected from 1.12.0; fixed in 1.17.3
- simplesamlphp/simplesamlphp (Packagist): affected from 1.12.0; fixed in 1.17.3

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/GHSA-vpr3-cw3h-prw8/ (Markdown: https://insights.sbomify.com/GHSA-vpr3-cw3h-prw8/index.md)
```

## Sources

- OSV: https://osv.dev/vulnerability/GHSA-vpr3-cw3h-prw8

---
From sbomify Insights: https://insights.sbomify.com/GHSA-vpr3-cw3h-prw8/
Summaries are generated and may contain mistakes; the official description above is the record.