WP-Matomo 1.1.9 currently ships an embedded tracker proxy that predates the security refactor added to the standalone matomo-org/tracker-proxy project in:
The affected WP-Matomo implementation is included under:
proxy/matomo.php
proxy/proxy.php
This embedded copy is insecure because it uses the older deny-list design for deciding when the site's configured Matomo token may be attached to an unauthenticated tracking request.
That design has multiple bypass classes, including:
- protected parameters that are missing from the deny list;
- bulk JSON requests whose nested tracking fields are not inspected;
- empty or malformed
token_auth values that suppress sanitization;
- inspection of parsed request parameters while forwarding different raw request bytes.
These gaps can allow an unauthenticated request to reuse the WordPress site's saved Matomo token for tracking fields that Matomo would normally reject without authentication.
The standalone tracker proxy already addressed this security problem by changing the design so the configured token is lent only to requests that contain no authentication or protected override parameters of their own. WP-Matomo has not yet received that hardening and therefore still exposes the older bypass-prone behavior.
Recommended security fix
Please port the complete security hardening from tracker-proxy PR #104 into WP-Matomo rather than applying individual parameter-specific patches.
The updated implementation should:
- inspect both normal and bulk tracking requests;
- inspect every nested request inside bulk payloads;
- withhold the configured proxy token whenever any authentication or protected override field is present;
- treat empty, array-valued, and malformed token values safely;
- ensure the exact request representation being forwarded is the one that was inspected;
- add regression tests covering the known bypass classes;
- publish the fix in a new WordPress.org release.
The earlier embedded proxy update appears to have been handled in:
Longer term, replacing the copied security-sensitive implementation with a shared maintained dependency would reduce the risk of future security fixes being applied to the standalone proxy but not propagated to WP-Matomo.
WP-Matomo 1.1.9 currently ships an embedded tracker proxy that predates the security refactor added to the standalone
matomo-org/tracker-proxyproject in:The affected WP-Matomo implementation is included under:
This embedded copy is insecure because it uses the older deny-list design for deciding when the site's configured Matomo token may be attached to an unauthenticated tracking request.
That design has multiple bypass classes, including:
token_authvalues that suppress sanitization;These gaps can allow an unauthenticated request to reuse the WordPress site's saved Matomo token for tracking fields that Matomo would normally reject without authentication.
The standalone tracker proxy already addressed this security problem by changing the design so the configured token is lent only to requests that contain no authentication or protected override parameters of their own. WP-Matomo has not yet received that hardening and therefore still exposes the older bypass-prone behavior.
Recommended security fix
Please port the complete security hardening from tracker-proxy PR #104 into WP-Matomo rather than applying individual parameter-specific patches.
The updated implementation should:
The earlier embedded proxy update appears to have been handled in:
Longer term, replacing the copied security-sensitive implementation with a shared maintained dependency would reduce the risk of future security fixes being applied to the standalone proxy but not propagated to WP-Matomo.