4 min to read

CVE-2025-64115: Unvalidated Referer Redirect & SSRF in Movary

Featured image

Author: Juan Soberanes (CyberDucky)
Date: 2025-10-30
Severity: High (CVSS 8.1)
CVE: CVE-2025-64115
GitHub Advisory: GHSA-pm58-79jw-q79f

References:

Overview

While reviewing the Movary codebase, I discovered a high-severity vulnerability caused by unvalidated use of the HTTP_REFERER header for redirects. This design flaw allowed attackers to abuse application redirect behavior, enabling both open redirect phishing campaigns and potential Server-Side Request Forgery (SSRF) attacks.

This issue was responsibly disclosed to the maintainers and has since been remediated.

Vulnerability Summary

Impact

Successful exploitation could allow for:

Vulnerable Endpoints

The following endpoints were found to perform redirects directly from the untrusted HTTP_REFERER header:

/settings/account/delete-history

/settings/account/delete-ratings

/settings/account/delete-account

Root Cause

The application trusted and used the value of:

$_SERVER['HTTP_REFERER']

as a redirect URL without verifying that the destination belonged to the same origin. Because Referer is a client-controlled request header, attackers could fully manipulate its value.

Example Attack

Open Redirect Phishing

  1. The attacker hosts a malicious webpage.
  2. The victim clicks a link leading to Movary from that page.
  3. The browser sends the attacker’s domain as the Referer header.
  4. Movary processes a request to one of the vulnerable endpoints.
  5. Movary redirects the victim right back to the attacker’s phishing page.

Once redirected, victims may be prompted to:

SSRF Abuse

Using crafted redirection flows, an attacker could coercively route server requests toward:

Scalability

This exploitation pattern requires:

The ease of exploitation enables large-scale abuse and automation.

Proof of Concept

The vulnerability was verified via live tests in a controlled local environment. Demonstrations included:

Full exploitation workflows were documented in the private disclosure reports.

Immediate Fix — Validate Referer Redirects

Only allow redirects to locations that remain within the application’s origin.

private function getSafeRedirectUrl(): string
{
    $referer = $_SERVER['HTTP_REFERER'] ?? '';
   
    if (empty($referer)) {
        return '/settings';
    }
   
    $refererParts = parse_url($referer);
    $currentHost = $_SERVER['HTTP_HOST'];
   
    // Only allow same-origin redirects
    if (isset($refererParts['host']) && $refererParts['host'] === $currentHost) {
        return $referer;
    }
   
    return '/settings';
}

Defense-in-Depth Recommendations

To further reduce attack surface:

Maintainer Fixes

Movary deployed two major fixes.

1. Global Referer Validation Middleware

Reference: Issue #713

2. HTTP Method Refactor

This prevents:

Reference: Issue #717

Disclosure Timeline

Date Event
2025-10-25 Vulnerability discovered and validated in local environment
2025-10-30 Initial responsible disclosure submitted
Following weeks Maintainer remediation and validation
After patch release Coordinated public disclosure

Testing Environment

Credits

Discovery & Disclosure

Juan Soberanes — CyberDucky GitHub: @cyberducky0o0

Final Notes

This vulnerability demonstrates a common but dangerous assumption:

Never trust HTTP headers as authoritative input.

Even fields that appear benign, such as Referer, can become powerful attack vectors when they influence application routing or redirection flows.

Proper validation and safer HTTP method usage are mandatory for preventing this class of attack.

🦆 CyberDucky Security Research Teaching exploitation, defense, and vulnerability research — one bug at a time.

Advertisement