High-severity findings.

Audited release

0.1.11

Findings

3

Worst severity

high

Content hash

97c4af8df5315d2c1a623d42… Copy

Findings

• high Unauthenticated REST proxy uses the merchant Gurado Access Token with no permission_callback

  missing_permission_callback

  register_rest_route for GET and POST /gurado-api/v1/proxy (and GET /gurado-api/v1/cartUrl) omit permission_callback. Since WordPress 5.5 that is _doing_it_wrong but the routes remain public: the REST server only invokes a permission callback when one is set. gurado_api_proxy reads get_option('gurado_api_settings'), sets Authorization: Bearer <gurado_api_secret>, and dispatches on the attacker-supplied endpoint query parameter via startsWith(). Public catalog reads are the intended storefront, but the same unauthenticated GET also: returns the Consumer Key (/clientId); calls https://api.gurado.de/v1.0/system-configuration with both X-GURADO-CONSUMER-KEY and X-GURADO-CONSUMER-SECRET and returns the body (/systemConfiguration — unused by the React app); creates/patches/deletes carts, adds items, applies redemptions, and POSTs /api/v1/orders (/invoiceOrder) with attacker JSON; registers customers, logs them in, sends password-reset and account-deletion codes, and with a Customer-Authorization token reads the wallet/profile or DELETEs the customer. All of those mutations are on GET, so they are CSRF-able (<img src>) and CORS-readable from any Origin (rest_send_cors_headers). The localized wp_rest nonce is never sent. GET /cartUrl calls undefined gurado_api_cartUrl (PHP fatal). Observable: any internet client who can reach /wp-json/gurado-api/v1/proxy can spend the merchant extension credential to place invoice/Vorkasse orders, mint customer accounts, and dump whatever system-configuration the consumer secret is allowed to read.

  gurado.php:423-446, 452-483, 513-525, 755-761

  Recommendation

  Add an explicit permission_callback. Keep truly public catalog GETs on a tight allowlist (products, countries, agreements, style) with rawurlencode'd path/query segments and POST-only for mutations. Require the wp_rest nonce (or a plugin nonce) plus, for customer-account operations, the Customer-Authorization header rather than a token query argument. Do not proxy /systemConfiguration or return the consumer key unless the payments SDK actually needs it. Remove the undefined /cartUrl route. Do not use GET for create/patch/delete/order/login.

• high Proxy interpolates unsanitized path params (../ breakout) and puts customer tokens/passwords on GET query strings

  information_disclosure

  gurado_api_proxy concatenates attacker-controlled cartId, sku, item_id, itemId, agreementId, redemptionId, and url_key into https://storefront.gurado.de/api/v1/... with no rawurlencode(). WordPress WP_Http uses libcurl with CURLOPT_PATH_AS_IS unset, so /../ is normalized before the request is sent. Empirically, GET https://storefront.gurado.de/api/v1/carts/x/../../customers is rewritten to https://storefront.gurado.de/api/v1/customers (HTTP 405 on unauthenticated GET — the collection exists). An unauthenticated caller of /wp-json/gurado-api/v1/proxy?endpoint=/getCart&cartId=x/../../customers (or /product&sku=x/../../orders, /getAgreement&agreementId=../customers, etc.) therefore hits arbitrary storefront paths with the merchant Bearer token, not only the intended resource. Separately, the same GET handler takes loginData, forgetPasswordData, registerData, and token from query params; the bundled helper/register.js actually issues those GETs (forgetPasswordForm, getMyProfile, saveMyProfile, getVouchers, voucherCode, deletionCode, logout, changePassword all append localStorage customerToken or JSON bodies to the URL). Those secrets land in web-server/CDN/WAF access logs and browser history; possession of a leaked token is sufficient to call /getMyProfile, /getVouchers, /saveMyProfile, or /deletionCode with no WordPress auth. Cart IDs in GET URLs similarly leak guest-cart PII (billing/email after /patchCart).

  gurado.php:484-495, 551-565, 601-612, 679-691, 728-739, 822-846, 961-981, 1006-1070

  Recommendation

  rawurlencode() every interpolated path and query segment; reject values containing /, ?, #, or .. . Map endpoint names to fully static URL templates (no caller-controlled path). Move login, password-reset, profile, wallet, and deletion payloads to POST JSON bodies; pass the customer token only as a header, never as a query argument. Treat cart IDs as secrets (POST body, not GET).

• medium Checkout password-change and payments SDK hardcoded to leftover developer host storefront-vahuja.dev.gurado.de

  insecure_config

  gurado_api_proxy_post's /changePassword branch wp_remote_request()s https://storefront-vahuja.dev.gurado.de/api/v1/customers/me/change-password with the production merchant Bearer token, the customer's Bearer token from the token query arg, and json_encode($data) (the new-password POST body). The bundled checkout PaymentWall creates a <script> whose src is '"https://storefront-vahuja.dev.gurado.de/payments-sdk/js?client_id=' + clientId + '&cart_id=' + cart_id (leading quote makes it a relative URL; client_id is the leaked consumer key). storefront-vahuja.dev.gurado.de and parent dev.gurado.de currently NXDOMAIN under gurado.de's AWS nameservers, so requests fail closed today and this is not an active skimmer/subdomain takeover. It is still production checkout/auth code pointing at a personal/dev hostname: if that name is ever pointed at attacker or shared-staging infrastructure, every install would ship merchant API secrets, customer tokens, password-change bodies, and payment-SDK execution there. The official storefront host used everywhere else is storefront.gurado.de.

  gurado.php:1128-1151

  Recommendation

  Replace every storefront-vahuja.dev.gurado.de URL with https://storefront.gurado.de (same host as the rest of the proxy). Drop the leading quote on the payments-sdk script src. Do not send production Access Tokens to non-production hosts.

WP Registry hashes the installable build and reports on that exact bytes-for-bytes copy. Embargoed findings are withheld until they are disclosed, so a clean verdict means nothing public is outstanding. WP Manifest does not audit code itself.