CVE-2026-54659: 
Ruby Analyse et atténuation des vulnérabilités

CVE-2026-54659 is a path traversal and information disclosure vulnerability in the Pagy Ruby pagination gem, specifically in the Pagy::I18n.locale= setter within gem/lib/pagy/modules/i18n/i18n.rb. The setter stored locale values verbatim and subsequently used them as path components when loading locale dictionary files (.yml), allowing untrusted params[:locale] values containing absolute paths or ../ sequences to redirect file lookups outside the intended locales directory. Affected versions are >= 43.0.0, < 43.5.6 of the pagy RubyGem (vendor: ddnexus). The vulnerability was reported by researcher 7a6163, fixed on June 8, 2026, and published to the GitHub Advisory Database on July 28, 2026. It carries a CVSS v4.0 base score of 6.9 (Medium) (Github Advisory, Pagy Advisory).

The root cause is improper input validation (CWE-22: Path Traversal; CWE-200: Exposure of Sensitive Information) in the locale= setter, which stored the raw string value directly into Thread.current[:pagy_locale] without any sanitization. When Pagy later resolved a translation, it constructed a file path by joining the locale value with .yml and calling YAML.load_file on the result — e.g., pathnames.reverse.map { |p| p.join("#{locale}.yml") }.find(&:exist?). An attacker supplying a value like ../../../config/database via the ?locale= query parameter could redirect this lookup to arbitrary .yml files on the filesystem. Exploitation requires no authentication or special privileges and is remotely triggerable over the network, but only affects applications that pass unsanitized end-user input directly into Pagy::I18n.locale= (e.g., the common pattern Pagy::I18n.locale = params[:locale]). A PoC is included in the official advisory (Github Advisory, Pagy Advisory).

The primary impact is a file-existence and readability oracle for .yml files on the host server: an attacker can infer whether a targeted .yml file exists and is readable by observing differences in application error responses. Additionally, the targeted file is read into the Ruby process during the attempt, though Pagy's structural check (dictionary['pagy']['p11n']) prevents file contents from being returned in the HTTP response, so this is not a direct file read exfiltration. Sensitive configuration files such as config/database.yml (containing database credentials) or config/secrets.yml could be probed and partially processed server-side. There is no integrity or availability impact; the vulnerability is limited to confidentiality of file metadata and server-side file reads (Github Advisory).

1. Reconnaissance: Identify Ruby web applications using the pagy gem (versions 43.0.0–43.5.5) that expose a locale-switching parameter (e.g., ?locale=) and pass it unsanitized to Pagy::I18n.locale=.
2. Determine traversal depth: Identify the relative path from the gem's locales/ directory to the application root. This typically requires a few ../ sequences (e.g., 3–5 levels depending on gem installation path).
3. Probe for file existence: Send a request such as GET /?locale=../../../config/database to the target application. Pagy appends .yml and attempts to load …/config/database.yml. Observe the response: a different error (e.g., YAML parse error or missing key error) compared to a non-existent path (which silently falls back to the default locale) reveals whether the file exists and is readable.
4. Enumerate sensitive files: Repeat step 3 with other known .yml file paths (e.g., config/secrets, config/credentials, config/application) to build a map of readable YAML configuration files on the server.
5. Infer sensitive data: While file contents are not returned in the HTTP response, the server-side read may trigger observable side effects (e.g., error messages referencing file content structure), and the oracle confirms the presence of sensitive configuration files for further attack planning (Github Advisory, Pagy Advisory).

• Network: HTTP requests containing ?locale= (or equivalent locale parameter) values with ../, absolute paths (e.g., /etc/), or non-BCP-47 strings (e.g., ../../../config/database) targeting paginated endpoints of Ruby web applications.
• Logs: Application/web server access logs showing repeated requests to paginated routes with unusual locale parameter values containing path traversal sequences; Ruby application error logs showing YAML::SyntaxError, NoMethodError, or Pagy::I18n::KeyError referencing unexpected file paths outside the gem's locales/ directory.
• Process: Ruby application process reading .yml files from unexpected directories (e.g., config/, /etc/) as observed via file access monitoring tools (e.g., auditd, inotifywait) (Github Advisory).

Upgrade the pagy gem to version 43.5.6 or later, which constrains the locale value to a BCP 47-compliant pattern (/\A[a-zA-Z]{2,8}(-[a-zA-Z0-9]{1,8})*\z/) before any file path operations, causing any non-matching value to silently resolve to the default locale (Pagy Release). If an immediate upgrade is not possible, apply the following workaround before assigning the locale: Pagy::I18n.locale = params[:locale].to_s[/\A[a-zA-Z]{2,8}(-[a-zA-Z0-9]{1,8})*\z/], or restrict the locale to a known allowlist of valid values. Only applications that pass unsanitized end-user input into Pagy::I18n.locale= are affected; applications using trusted/hardcoded locale values require no action (Github Advisory).