"However, it has been found that this security layer can be bypassed every time the "direct request" is enabled by supplying an "origin" parameter set to "mo" and a "type" parameter set to any value (e.g., "origin=mo&type=xxx"). This causes the request to be treated as a Modular direct request. "Therefore, as soon as the site has already been connected to Modular (tokens present/renewable), anyone can pass the auth middleware: there is no cryptographic link between the incoming request and Modular itself," Patchstack explained."
""This exposes several routes, including /login/, /server-information/, /manager/, and /backup/, which allow various actions to be performed, ranging from remote login to obtaining sensitive system or user data." As a result of this loophole, an unauthenticated attacker can exploit the "/login/{modular_request}" route to get administrator access, resulting in privilege escalation. This could then pave the way for a full site compromise, permitting an attacker to introduce malicious change"
A maximum-severity vulnerability in the Modular DS WordPress plugin, CVE-2026-23550 (CVSS 10.0), enables unauthenticated privilege escalation in versions up to 2.5.1. The vulnerability has been patched in version 2.5.2. The problem is rooted in the plugin's routing mechanism exposing endpoints under the /api/modular-connector/ prefix. When "direct request" is enabled and an origin=mo and type parameter are supplied, requests are treated as Modular direct requests and authentication can be bypassed. Sites already connected to Modular with renewable tokens can pass the auth middleware because requests lack a cryptographic link to Modular. Exposed routes include /login/, /server-information/, /manager/, and /backup/, enabling remote admin login, data access, and potential full site compromise.
Read at The Hacker News
Unable to calculate read time
Collection
[
|
...
]