pagy

Version	Released
`43.6.2` patch	Aug 24, 2026
`43.6.1` patch	Jul 21, 2026
`43.6.0` minor	Jul 09, 2026
`43.5.6` patch	Jun 08, 2026
`43.5.5` patch 1 CVE	May 24, 2026
`43.5.4` patch 1 CVE	May 13, 2026
`43.5.3` patch 1 CVE	Apr 26, 2026
`43.5.2` patch 1 CVE	Apr 24, 2026
`43.5.1` patch 1 CVE	Apr 13, 2026
`43.5.0` minor 1 CVE	Apr 08, 2026
`43.4.4` patch 1 CVE	Mar 27, 2026
`43.4.3` patch 1 CVE	Mar 25, 2026
`43.4.2` patch 1 CVE	Mar 21, 2026
`43.4.1` patch 1 CVE	Mar 19, 2026
`43.4.0` minor 1 CVE	Mar 16, 2026
`43.3.3` patch 1 CVE	Mar 13, 2026
`43.3.2` patch 1 CVE	Mar 10, 2026
`43.3.1` patch 1 CVE	Feb 26, 2026
`43.3.0` minor 1 CVE	Feb 21, 2026
`43.2.10` patch 1 CVE	Feb 17, 2026
`43.2.9` patch 1 CVE	Feb 05, 2026
`43.2.8` patch 1 CVE	Jan 24, 2026
`43.2.7` patch 1 CVE	Jan 20, 2026
`43.2.6` patch 1 CVE	Jan 16, 2026
`43.2.5` patch 1 CVE	Jan 16, 2026
`43.2.4` patch 1 CVE	Jan 13, 2026
`43.2.3` patch 1 CVE	Jan 10, 2026
`43.2.2` patch 1 CVE	Dec 18, 2025
`43.2.1` patch 1 CVE	Dec 14, 2025
`43.2.0` minor 1 CVE	Dec 04, 2025
`43.1.8` patch 1 CVE	Nov 28, 2025
`43.1.7` patch 1 CVE	Nov 28, 2025
`43.1.6` patch 1 CVE	Nov 26, 2025
`43.1.5` patch 1 CVE	Nov 26, 2025
`43.1.4` patch 1 CVE	Nov 24, 2025
`43.1.3` patch 1 CVE	Nov 23, 2025
`43.1.2` patch 1 CVE	Nov 22, 2025
`43.1.1` patch 1 CVE	Nov 21, 2025
`43.1.0` minor 1 CVE	Nov 20, 2025
`43.0.7` patch 1 CVE	Nov 18, 2025
`43.0.6` patch 1 CVE	Nov 15, 2025
`43.0.5` patch 1 CVE	Nov 14, 2025
`43.0.4` patch 1 CVE	Nov 13, 2025
`43.0.3` patch 1 CVE	Nov 12, 2025
`43.0.2` patch 1 CVE	Nov 11, 2025
`43.0.1` patch 1 CVE	Nov 11, 2025
`43.0.0` major 1 CVE	Nov 03, 2025
`43.0.0.rc4` pre	Aug 20, 2025
`43.0.0.rc3` pre	Aug 17, 2025
`9.4.0` minor	Aug 13, 2025

43.6.2 patch

Aug 24, 2026

43.6.1 patch

Jul 21, 2026

43.6.0 minor

Jul 09, 2026

43.5.6 patch

Jun 08, 2026

43.5.5 patch

1 CVE

CVE-2026-54659 GHSA-2xmw-f8j8-wfxc Jul 28, 2026

Pagy I18n locale option is not validated before being used in a file path

Medium

Network Low None None

Summary

Pagy::I18n.locale= did not validate its argument before using it as a path component to load the matching dictionary file (<locale>.yml). An application that assigns untrusted input to the locale — e.g. the common pattern Pagy::I18n.locale = params[:locale] — let that input influence which file Pagy attempted to load.

Details

The setter stored the value as-is, and the loader joined it into a path and read it:

# gem/lib/pagy/modules/i18n/i18n.rb
def locale=(value)
  Thread.current[:pagy_locale] = value.to_s
end

# ...later, when translating:
path = pathnames.reverse.map { |p| p.join("#{locale}.yml") }.find(&:exist?)
dictionary = YAML.load_file(path)[locale]

Because the locale was used verbatim, a value such as an absolute path or a ../-style string redirected the lookup outside the locales directory. Pagy's subsequent structural check (dictionary['pagy']['p11n']) prevents the file's contents from being returned, so this is not a direct file read.

Fixed in 43.5.6 by constraining the locale to a BCP 47 shape before use:

LOCALE_PATTERN = /\A[a-zA-Z]{2,8}(-[a-zA-Z0-9]{1,8})*\z/

def locale=(value)
  Thread.current[:pagy_locale] = value.to_s[LOCALE_PATTERN]
end

Any non-matching value (including nil) resolves to the default locale and never reaches the file lookup.

PoC

In an application that sets Pagy::I18n.locale = params[:locale], the loader appends .yml and reads <locale>.yml, so the request param controls the target path. For example, pointing it at the app's config/database.yml:

Send a request with ?locale=../../../config/database (adjust the number of ../ to reach the app root from the gem's locales/ directory).
Pagy calls YAML.load_file on the resulting …/config/database.yml.
The outcome differs by whether that .yml exists, is readable, parses as YAML, and has Pagy's expected structure — an existing, readable config/database.yml raises a different error than a non-existent path (which silently falls back to the default locale). This yields a file-existence / readability oracle for .yml paths, and the targeted file is read into the process during the attempt.

Impact

Information disclosure (CWE-22 / CWE-200): a file-existence / readability oracle for .yml paths on the host, plus a server-side read of attacker-chosen files into the process. The file contents are not returned in the response.

Only applications that pass unsanitized end-user input into Pagy::I18n.locale= are affected. Applications that set the locale from trusted values are not affected.

Patched: pagy 43.5.6. Workaround (if you cannot upgrade): validate the locale before assigning it, e.g. Pagy::I18n.locale = params[:locale].to_s[/\A[a-zA-Z]{2,8}(-[a-zA-Z0-9]{1,8})*\z/], or restrict it to your known set of locales.

Affected versions


          43.0.0


          43.0.1


          43.0.2


          43.0.3


          43.0.4


          43.0.5


          43.0.6


          43.0.7


          43.1.0


          43.1.1


          43.1.2


          43.1.3

+ 31 more


            43.1.4


            43.1.5


            43.1.6


            43.1.7


            43.1.8


            43.2.0


            43.2.1


            43.2.10


            43.2.2


            43.2.3


            43.2.4


            43.2.5


            43.2.6


            43.2.7


            43.2.8


            43.2.9


            43.3.0


            43.3.1


            43.3.2


            43.3.3


            43.4.0


            43.4.1


            43.4.2


            43.4.3


            43.4.4


            43.5.0


            43.5.1


            43.5.2


            43.5.3


            43.5.4


            43.5.5

Fixed in


          43.5.6

References

Updated Jul 28, 2026 · Source: OSV.dev

May 24, 2026

43.5.4 patch

1 CVE

CVE-2026-54659 GHSA-2xmw-f8j8-wfxc Jul 28, 2026

Pagy I18n locale option is not validated before being used in a file path

Medium

Network Low None None

Summary

Pagy::I18n.locale= did not validate its argument before using it as a path component to load the matching dictionary file (<locale>.yml). An application that assigns untrusted input to the locale — e.g. the common pattern Pagy::I18n.locale = params[:locale] — let that input influence which file Pagy attempted to load.

Details

The setter stored the value as-is, and the loader joined it into a path and read it:

# gem/lib/pagy/modules/i18n/i18n.rb
def locale=(value)
  Thread.current[:pagy_locale] = value.to_s
end

# ...later, when translating:
path = pathnames.reverse.map { |p| p.join("#{locale}.yml") }.find(&:exist?)
dictionary = YAML.load_file(path)[locale]

Because the locale was used verbatim, a value such as an absolute path or a ../-style string redirected the lookup outside the locales directory. Pagy's subsequent structural check (dictionary['pagy']['p11n']) prevents the file's contents from being returned, so this is not a direct file read.

Fixed in 43.5.6 by constraining the locale to a BCP 47 shape before use:

LOCALE_PATTERN = /\A[a-zA-Z]{2,8}(-[a-zA-Z0-9]{1,8})*\z/

def locale=(value)
  Thread.current[:pagy_locale] = value.to_s[LOCALE_PATTERN]
end

Any non-matching value (including nil) resolves to the default locale and never reaches the file lookup.

PoC

In an application that sets Pagy::I18n.locale = params[:locale], the loader appends .yml and reads <locale>.yml, so the request param controls the target path. For example, pointing it at the app's config/database.yml:

Send a request with ?locale=../../../config/database (adjust the number of ../ to reach the app root from the gem's locales/ directory).
Pagy calls YAML.load_file on the resulting …/config/database.yml.
The outcome differs by whether that .yml exists, is readable, parses as YAML, and has Pagy's expected structure — an existing, readable config/database.yml raises a different error than a non-existent path (which silently falls back to the default locale). This yields a file-existence / readability oracle for .yml paths, and the targeted file is read into the process during the attempt.

Impact

Information disclosure (CWE-22 / CWE-200): a file-existence / readability oracle for .yml paths on the host, plus a server-side read of attacker-chosen files into the process. The file contents are not returned in the response.

Only applications that pass unsanitized end-user input into Pagy::I18n.locale= are affected. Applications that set the locale from trusted values are not affected.

Patched: pagy 43.5.6. Workaround (if you cannot upgrade): validate the locale before assigning it, e.g. Pagy::I18n.locale = params[:locale].to_s[/\A[a-zA-Z]{2,8}(-[a-zA-Z0-9]{1,8})*\z/], or restrict it to your known set of locales.

Affected versions


          43.0.0


          43.0.1


          43.0.2


          43.0.3


          43.0.4


          43.0.5


          43.0.6


          43.0.7


          43.1.0


          43.1.1


          43.1.2


          43.1.3

+ 31 more


            43.1.4


            43.1.5


            43.1.6


            43.1.7


            43.1.8


            43.2.0


            43.2.1


            43.2.10


            43.2.2


            43.2.3


            43.2.4


            43.2.5


            43.2.6


            43.2.7


            43.2.8


            43.2.9


            43.3.0


            43.3.1


            43.3.2


            43.3.3


            43.4.0


            43.4.1


            43.4.2


            43.4.3


            43.4.4


            43.5.0


            43.5.1


            43.5.2


            43.5.3


            43.5.4


            43.5.5

Fixed in


          43.5.6

References

Updated Jul 28, 2026 · Source: OSV.dev

May 13, 2026

43.5.3 patch

1 CVE

CVE-2026-54659 GHSA-2xmw-f8j8-wfxc Jul 28, 2026

Pagy I18n locale option is not validated before being used in a file path

Medium

Network Low None None

Summary

Pagy::I18n.locale= did not validate its argument before using it as a path component to load the matching dictionary file (<locale>.yml). An application that assigns untrusted input to the locale — e.g. the common pattern Pagy::I18n.locale = params[:locale] — let that input influence which file Pagy attempted to load.

Details

The setter stored the value as-is, and the loader joined it into a path and read it:

# gem/lib/pagy/modules/i18n/i18n.rb
def locale=(value)
  Thread.current[:pagy_locale] = value.to_s
end

# ...later, when translating:
path = pathnames.reverse.map { |p| p.join("#{locale}.yml") }.find(&:exist?)
dictionary = YAML.load_file(path)[locale]

Because the locale was used verbatim, a value such as an absolute path or a ../-style string redirected the lookup outside the locales directory. Pagy's subsequent structural check (dictionary['pagy']['p11n']) prevents the file's contents from being returned, so this is not a direct file read.

Fixed in 43.5.6 by constraining the locale to a BCP 47 shape before use:

LOCALE_PATTERN = /\A[a-zA-Z]{2,8}(-[a-zA-Z0-9]{1,8})*\z/

def locale=(value)
  Thread.current[:pagy_locale] = value.to_s[LOCALE_PATTERN]
end

Any non-matching value (including nil) resolves to the default locale and never reaches the file lookup.

PoC

In an application that sets Pagy::I18n.locale = params[:locale], the loader appends .yml and reads <locale>.yml, so the request param controls the target path. For example, pointing it at the app's config/database.yml:

Send a request with ?locale=../../../config/database (adjust the number of ../ to reach the app root from the gem's locales/ directory).
Pagy calls YAML.load_file on the resulting …/config/database.yml.
The outcome differs by whether that .yml exists, is readable, parses as YAML, and has Pagy's expected structure — an existing, readable config/database.yml raises a different error than a non-existent path (which silently falls back to the default locale). This yields a file-existence / readability oracle for .yml paths, and the targeted file is read into the process during the attempt.

Impact

Information disclosure (CWE-22 / CWE-200): a file-existence / readability oracle for .yml paths on the host, plus a server-side read of attacker-chosen files into the process. The file contents are not returned in the response.

Only applications that pass unsanitized end-user input into Pagy::I18n.locale= are affected. Applications that set the locale from trusted values are not affected.

Patched: pagy 43.5.6. Workaround (if you cannot upgrade): validate the locale before assigning it, e.g. Pagy::I18n.locale = params[:locale].to_s[/\A[a-zA-Z]{2,8}(-[a-zA-Z0-9]{1,8})*\z/], or restrict it to your known set of locales.

Affected versions


          43.0.0


          43.0.1


          43.0.2


          43.0.3


          43.0.4


          43.0.5


          43.0.6


          43.0.7


          43.1.0


          43.1.1


          43.1.2


          43.1.3

+ 31 more


            43.1.4


            43.1.5


            43.1.6


            43.1.7


            43.1.8


            43.2.0


            43.2.1


            43.2.10


            43.2.2


            43.2.3


            43.2.4


            43.2.5


            43.2.6


            43.2.7


            43.2.8


            43.2.9


            43.3.0


            43.3.1


            43.3.2


            43.3.3


            43.4.0


            43.4.1


            43.4.2


            43.4.3


            43.4.4


            43.5.0


            43.5.1


            43.5.2


            43.5.3


            43.5.4


            43.5.5

Fixed in


          43.5.6

References

Updated Jul 28, 2026 · Source: OSV.dev

Apr 26, 2026

43.5.2 patch

1 CVE

CVE-2026-54659 GHSA-2xmw-f8j8-wfxc Jul 28, 2026

Pagy I18n locale option is not validated before being used in a file path

Medium

Network Low None None

Summary

Pagy::I18n.locale= did not validate its argument before using it as a path component to load the matching dictionary file (<locale>.yml). An application that assigns untrusted input to the locale — e.g. the common pattern Pagy::I18n.locale = params[:locale] — let that input influence which file Pagy attempted to load.

Details

The setter stored the value as-is, and the loader joined it into a path and read it:

# gem/lib/pagy/modules/i18n/i18n.rb
def locale=(value)
  Thread.current[:pagy_locale] = value.to_s
end

# ...later, when translating:
path = pathnames.reverse.map { |p| p.join("#{locale}.yml") }.find(&:exist?)
dictionary = YAML.load_file(path)[locale]

Because the locale was used verbatim, a value such as an absolute path or a ../-style string redirected the lookup outside the locales directory. Pagy's subsequent structural check (dictionary['pagy']['p11n']) prevents the file's contents from being returned, so this is not a direct file read.

Fixed in 43.5.6 by constraining the locale to a BCP 47 shape before use:

LOCALE_PATTERN = /\A[a-zA-Z]{2,8}(-[a-zA-Z0-9]{1,8})*\z/

def locale=(value)
  Thread.current[:pagy_locale] = value.to_s[LOCALE_PATTERN]
end

Any non-matching value (including nil) resolves to the default locale and never reaches the file lookup.

PoC

In an application that sets Pagy::I18n.locale = params[:locale], the loader appends .yml and reads <locale>.yml, so the request param controls the target path. For example, pointing it at the app's config/database.yml:

Send a request with ?locale=../../../config/database (adjust the number of ../ to reach the app root from the gem's locales/ directory).
Pagy calls YAML.load_file on the resulting …/config/database.yml.
The outcome differs by whether that .yml exists, is readable, parses as YAML, and has Pagy's expected structure — an existing, readable config/database.yml raises a different error than a non-existent path (which silently falls back to the default locale). This yields a file-existence / readability oracle for .yml paths, and the targeted file is read into the process during the attempt.

Impact

Information disclosure (CWE-22 / CWE-200): a file-existence / readability oracle for .yml paths on the host, plus a server-side read of attacker-chosen files into the process. The file contents are not returned in the response.

Only applications that pass unsanitized end-user input into Pagy::I18n.locale= are affected. Applications that set the locale from trusted values are not affected.

Patched: pagy 43.5.6. Workaround (if you cannot upgrade): validate the locale before assigning it, e.g. Pagy::I18n.locale = params[:locale].to_s[/\A[a-zA-Z]{2,8}(-[a-zA-Z0-9]{1,8})*\z/], or restrict it to your known set of locales.

Affected versions


          43.0.0


          43.0.1


          43.0.2


          43.0.3


          43.0.4


          43.0.5


          43.0.6


          43.0.7


          43.1.0


          43.1.1


          43.1.2


          43.1.3

+ 31 more


            43.1.4


            43.1.5


            43.1.6


            43.1.7


            43.1.8


            43.2.0


            43.2.1


            43.2.10


            43.2.2


            43.2.3


            43.2.4


            43.2.5


            43.2.6


            43.2.7


            43.2.8


            43.2.9


            43.3.0


            43.3.1


            43.3.2


            43.3.3


            43.4.0


            43.4.1


            43.4.2


            43.4.3


            43.4.4


            43.5.0


            43.5.1


            43.5.2


            43.5.3


            43.5.4


            43.5.5

Fixed in


          43.5.6

References

Updated Jul 28, 2026 · Source: OSV.dev

Apr 24, 2026

43.5.1 patch

1 CVE

CVE-2026-54659 GHSA-2xmw-f8j8-wfxc Jul 28, 2026

Pagy I18n locale option is not validated before being used in a file path

Medium

Network Low None None

Summary

Pagy::I18n.locale= did not validate its argument before using it as a path component to load the matching dictionary file (<locale>.yml). An application that assigns untrusted input to the locale — e.g. the common pattern Pagy::I18n.locale = params[:locale] — let that input influence which file Pagy attempted to load.

Details

The setter stored the value as-is, and the loader joined it into a path and read it:

# gem/lib/pagy/modules/i18n/i18n.rb
def locale=(value)
  Thread.current[:pagy_locale] = value.to_s
end

# ...later, when translating:
path = pathnames.reverse.map { |p| p.join("#{locale}.yml") }.find(&:exist?)
dictionary = YAML.load_file(path)[locale]

Because the locale was used verbatim, a value such as an absolute path or a ../-style string redirected the lookup outside the locales directory. Pagy's subsequent structural check (dictionary['pagy']['p11n']) prevents the file's contents from being returned, so this is not a direct file read.

Fixed in 43.5.6 by constraining the locale to a BCP 47 shape before use:

LOCALE_PATTERN = /\A[a-zA-Z]{2,8}(-[a-zA-Z0-9]{1,8})*\z/

def locale=(value)
  Thread.current[:pagy_locale] = value.to_s[LOCALE_PATTERN]
end

Any non-matching value (including nil) resolves to the default locale and never reaches the file lookup.

PoC

In an application that sets Pagy::I18n.locale = params[:locale], the loader appends .yml and reads <locale>.yml, so the request param controls the target path. For example, pointing it at the app's config/database.yml:

Send a request with ?locale=../../../config/database (adjust the number of ../ to reach the app root from the gem's locales/ directory).
Pagy calls YAML.load_file on the resulting …/config/database.yml.
The outcome differs by whether that .yml exists, is readable, parses as YAML, and has Pagy's expected structure — an existing, readable config/database.yml raises a different error than a non-existent path (which silently falls back to the default locale). This yields a file-existence / readability oracle for .yml paths, and the targeted file is read into the process during the attempt.

Impact

Information disclosure (CWE-22 / CWE-200): a file-existence / readability oracle for .yml paths on the host, plus a server-side read of attacker-chosen files into the process. The file contents are not returned in the response.

Only applications that pass unsanitized end-user input into Pagy::I18n.locale= are affected. Applications that set the locale from trusted values are not affected.

Patched: pagy 43.5.6. Workaround (if you cannot upgrade): validate the locale before assigning it, e.g. Pagy::I18n.locale = params[:locale].to_s[/\A[a-zA-Z]{2,8}(-[a-zA-Z0-9]{1,8})*\z/], or restrict it to your known set of locales.

Affected versions


          43.0.0


          43.0.1


          43.0.2


          43.0.3


          43.0.4


          43.0.5


          43.0.6


          43.0.7


          43.1.0


          43.1.1


          43.1.2


          43.1.3

+ 31 more


            43.1.4


            43.1.5


            43.1.6


            43.1.7


            43.1.8


            43.2.0


            43.2.1


            43.2.10


            43.2.2


            43.2.3


            43.2.4


            43.2.5


            43.2.6


            43.2.7


            43.2.8


            43.2.9


            43.3.0


            43.3.1


            43.3.2


            43.3.3


            43.4.0


            43.4.1


            43.4.2


            43.4.3


            43.4.4


            43.5.0


            43.5.1


            43.5.2


            43.5.3


            43.5.4


            43.5.5

Fixed in


          43.5.6

References

Updated Jul 28, 2026 · Source: OSV.dev

Apr 13, 2026

43.5.0 minor

1 CVE

CVE-2026-54659 GHSA-2xmw-f8j8-wfxc Jul 28, 2026

Pagy I18n locale option is not validated before being used in a file path

Medium

Network Low None None

Summary

Pagy::I18n.locale= did not validate its argument before using it as a path component to load the matching dictionary file (<locale>.yml). An application that assigns untrusted input to the locale — e.g. the common pattern Pagy::I18n.locale = params[:locale] — let that input influence which file Pagy attempted to load.

Details

The setter stored the value as-is, and the loader joined it into a path and read it:

# gem/lib/pagy/modules/i18n/i18n.rb
def locale=(value)
  Thread.current[:pagy_locale] = value.to_s
end

# ...later, when translating:
path = pathnames.reverse.map { |p| p.join("#{locale}.yml") }.find(&:exist?)
dictionary = YAML.load_file(path)[locale]

Because the locale was used verbatim, a value such as an absolute path or a ../-style string redirected the lookup outside the locales directory. Pagy's subsequent structural check (dictionary['pagy']['p11n']) prevents the file's contents from being returned, so this is not a direct file read.

Fixed in 43.5.6 by constraining the locale to a BCP 47 shape before use:

LOCALE_PATTERN = /\A[a-zA-Z]{2,8}(-[a-zA-Z0-9]{1,8})*\z/

def locale=(value)
  Thread.current[:pagy_locale] = value.to_s[LOCALE_PATTERN]
end

Any non-matching value (including nil) resolves to the default locale and never reaches the file lookup.

PoC

In an application that sets Pagy::I18n.locale = params[:locale], the loader appends .yml and reads <locale>.yml, so the request param controls the target path. For example, pointing it at the app's config/database.yml:

Send a request with ?locale=../../../config/database (adjust the number of ../ to reach the app root from the gem's locales/ directory).
Pagy calls YAML.load_file on the resulting …/config/database.yml.
The outcome differs by whether that .yml exists, is readable, parses as YAML, and has Pagy's expected structure — an existing, readable config/database.yml raises a different error than a non-existent path (which silently falls back to the default locale). This yields a file-existence / readability oracle for .yml paths, and the targeted file is read into the process during the attempt.

Impact

Information disclosure (CWE-22 / CWE-200): a file-existence / readability oracle for .yml paths on the host, plus a server-side read of attacker-chosen files into the process. The file contents are not returned in the response.

Only applications that pass unsanitized end-user input into Pagy::I18n.locale= are affected. Applications that set the locale from trusted values are not affected.

Patched: pagy 43.5.6. Workaround (if you cannot upgrade): validate the locale before assigning it, e.g. Pagy::I18n.locale = params[:locale].to_s[/\A[a-zA-Z]{2,8}(-[a-zA-Z0-9]{1,8})*\z/], or restrict it to your known set of locales.

Affected versions


          43.0.0


          43.0.1


          43.0.2


          43.0.3


          43.0.4


          43.0.5


          43.0.6


          43.0.7


          43.1.0


          43.1.1


          43.1.2


          43.1.3

+ 31 more


            43.1.4


            43.1.5


            43.1.6


            43.1.7


            43.1.8


            43.2.0


            43.2.1


            43.2.10


            43.2.2


            43.2.3


            43.2.4


            43.2.5


            43.2.6


            43.2.7


            43.2.8


            43.2.9


            43.3.0


            43.3.1


            43.3.2


            43.3.3


            43.4.0


            43.4.1


            43.4.2


            43.4.3


            43.4.4


            43.5.0


            43.5.1


            43.5.2


            43.5.3


            43.5.4


            43.5.5

Fixed in


          43.5.6

References

Updated Jul 28, 2026 · Source: OSV.dev

Apr 08, 2026

43.4.4 patch

1 CVE

CVE-2026-54659 GHSA-2xmw-f8j8-wfxc Jul 28, 2026

Pagy I18n locale option is not validated before being used in a file path

Medium

Network Low None None

Summary

Pagy::I18n.locale= did not validate its argument before using it as a path component to load the matching dictionary file (<locale>.yml). An application that assigns untrusted input to the locale — e.g. the common pattern Pagy::I18n.locale = params[:locale] — let that input influence which file Pagy attempted to load.

Details

The setter stored the value as-is, and the loader joined it into a path and read it:

# gem/lib/pagy/modules/i18n/i18n.rb
def locale=(value)
  Thread.current[:pagy_locale] = value.to_s
end

# ...later, when translating:
path = pathnames.reverse.map { |p| p.join("#{locale}.yml") }.find(&:exist?)
dictionary = YAML.load_file(path)[locale]

Because the locale was used verbatim, a value such as an absolute path or a ../-style string redirected the lookup outside the locales directory. Pagy's subsequent structural check (dictionary['pagy']['p11n']) prevents the file's contents from being returned, so this is not a direct file read.

Fixed in 43.5.6 by constraining the locale to a BCP 47 shape before use:

LOCALE_PATTERN = /\A[a-zA-Z]{2,8}(-[a-zA-Z0-9]{1,8})*\z/

def locale=(value)
  Thread.current[:pagy_locale] = value.to_s[LOCALE_PATTERN]
end

Any non-matching value (including nil) resolves to the default locale and never reaches the file lookup.

PoC

In an application that sets Pagy::I18n.locale = params[:locale], the loader appends .yml and reads <locale>.yml, so the request param controls the target path. For example, pointing it at the app's config/database.yml:

Send a request with ?locale=../../../config/database (adjust the number of ../ to reach the app root from the gem's locales/ directory).
Pagy calls YAML.load_file on the resulting …/config/database.yml.
The outcome differs by whether that .yml exists, is readable, parses as YAML, and has Pagy's expected structure — an existing, readable config/database.yml raises a different error than a non-existent path (which silently falls back to the default locale). This yields a file-existence / readability oracle for .yml paths, and the targeted file is read into the process during the attempt.

Impact

Information disclosure (CWE-22 / CWE-200): a file-existence / readability oracle for .yml paths on the host, plus a server-side read of attacker-chosen files into the process. The file contents are not returned in the response.

Only applications that pass unsanitized end-user input into Pagy::I18n.locale= are affected. Applications that set the locale from trusted values are not affected.

Patched: pagy 43.5.6. Workaround (if you cannot upgrade): validate the locale before assigning it, e.g. Pagy::I18n.locale = params[:locale].to_s[/\A[a-zA-Z]{2,8}(-[a-zA-Z0-9]{1,8})*\z/], or restrict it to your known set of locales.

Affected versions


          43.0.0


          43.0.1


          43.0.2


          43.0.3


          43.0.4


          43.0.5


          43.0.6


          43.0.7


          43.1.0


          43.1.1


          43.1.2


          43.1.3

+ 31 more


            43.1.4


            43.1.5


            43.1.6


            43.1.7


            43.1.8


            43.2.0


            43.2.1


            43.2.10


            43.2.2


            43.2.3


            43.2.4


            43.2.5


            43.2.6


            43.2.7


            43.2.8


            43.2.9


            43.3.0


            43.3.1


            43.3.2


            43.3.3


            43.4.0


            43.4.1


            43.4.2


            43.4.3


            43.4.4


            43.5.0


            43.5.1


            43.5.2


            43.5.3


            43.5.4


            43.5.5

Fixed in


          43.5.6

References

Updated Jul 28, 2026 · Source: OSV.dev

Mar 27, 2026

43.4.3 patch

1 CVE

CVE-2026-54659 GHSA-2xmw-f8j8-wfxc Jul 28, 2026

Pagy I18n locale option is not validated before being used in a file path

Medium

Network Low None None

Summary

Pagy::I18n.locale= did not validate its argument before using it as a path component to load the matching dictionary file (<locale>.yml). An application that assigns untrusted input to the locale — e.g. the common pattern Pagy::I18n.locale = params[:locale] — let that input influence which file Pagy attempted to load.

Details

The setter stored the value as-is, and the loader joined it into a path and read it:

# gem/lib/pagy/modules/i18n/i18n.rb
def locale=(value)
  Thread.current[:pagy_locale] = value.to_s
end

# ...later, when translating:
path = pathnames.reverse.map { |p| p.join("#{locale}.yml") }.find(&:exist?)
dictionary = YAML.load_file(path)[locale]

Because the locale was used verbatim, a value such as an absolute path or a ../-style string redirected the lookup outside the locales directory. Pagy's subsequent structural check (dictionary['pagy']['p11n']) prevents the file's contents from being returned, so this is not a direct file read.

Fixed in 43.5.6 by constraining the locale to a BCP 47 shape before use:

LOCALE_PATTERN = /\A[a-zA-Z]{2,8}(-[a-zA-Z0-9]{1,8})*\z/

def locale=(value)
  Thread.current[:pagy_locale] = value.to_s[LOCALE_PATTERN]
end

Any non-matching value (including nil) resolves to the default locale and never reaches the file lookup.

PoC

In an application that sets Pagy::I18n.locale = params[:locale], the loader appends .yml and reads <locale>.yml, so the request param controls the target path. For example, pointing it at the app's config/database.yml:

Send a request with ?locale=../../../config/database (adjust the number of ../ to reach the app root from the gem's locales/ directory).
Pagy calls YAML.load_file on the resulting …/config/database.yml.
The outcome differs by whether that .yml exists, is readable, parses as YAML, and has Pagy's expected structure — an existing, readable config/database.yml raises a different error than a non-existent path (which silently falls back to the default locale). This yields a file-existence / readability oracle for .yml paths, and the targeted file is read into the process during the attempt.

Impact

Information disclosure (CWE-22 / CWE-200): a file-existence / readability oracle for .yml paths on the host, plus a server-side read of attacker-chosen files into the process. The file contents are not returned in the response.

Only applications that pass unsanitized end-user input into Pagy::I18n.locale= are affected. Applications that set the locale from trusted values are not affected.

Patched: pagy 43.5.6. Workaround (if you cannot upgrade): validate the locale before assigning it, e.g. Pagy::I18n.locale = params[:locale].to_s[/\A[a-zA-Z]{2,8}(-[a-zA-Z0-9]{1,8})*\z/], or restrict it to your known set of locales.

Affected versions


          43.0.0


          43.0.1


          43.0.2


          43.0.3


          43.0.4


          43.0.5


          43.0.6


          43.0.7


          43.1.0


          43.1.1


          43.1.2


          43.1.3

+ 31 more


            43.1.4


            43.1.5


            43.1.6


            43.1.7


            43.1.8


            43.2.0


            43.2.1


            43.2.10


            43.2.2


            43.2.3


            43.2.4


            43.2.5


            43.2.6


            43.2.7


            43.2.8


            43.2.9


            43.3.0


            43.3.1


            43.3.2


            43.3.3


            43.4.0


            43.4.1


            43.4.2


            43.4.3


            43.4.4


            43.5.0


            43.5.1


            43.5.2


            43.5.3


            43.5.4


            43.5.5

Fixed in


          43.5.6

References

Updated Jul 28, 2026 · Source: OSV.dev

Mar 25, 2026

43.4.2 patch

1 CVE

CVE-2026-54659 GHSA-2xmw-f8j8-wfxc Jul 28, 2026

Pagy I18n locale option is not validated before being used in a file path

Medium

Network Low None None

Summary

Pagy::I18n.locale= did not validate its argument before using it as a path component to load the matching dictionary file (<locale>.yml). An application that assigns untrusted input to the locale — e.g. the common pattern Pagy::I18n.locale = params[:locale] — let that input influence which file Pagy attempted to load.

Details

The setter stored the value as-is, and the loader joined it into a path and read it:

# gem/lib/pagy/modules/i18n/i18n.rb
def locale=(value)
  Thread.current[:pagy_locale] = value.to_s
end

# ...later, when translating:
path = pathnames.reverse.map { |p| p.join("#{locale}.yml") }.find(&:exist?)
dictionary = YAML.load_file(path)[locale]

Because the locale was used verbatim, a value such as an absolute path or a ../-style string redirected the lookup outside the locales directory. Pagy's subsequent structural check (dictionary['pagy']['p11n']) prevents the file's contents from being returned, so this is not a direct file read.

Fixed in 43.5.6 by constraining the locale to a BCP 47 shape before use:

LOCALE_PATTERN = /\A[a-zA-Z]{2,8}(-[a-zA-Z0-9]{1,8})*\z/

def locale=(value)
  Thread.current[:pagy_locale] = value.to_s[LOCALE_PATTERN]
end

Any non-matching value (including nil) resolves to the default locale and never reaches the file lookup.

PoC

In an application that sets Pagy::I18n.locale = params[:locale], the loader appends .yml and reads <locale>.yml, so the request param controls the target path. For example, pointing it at the app's config/database.yml:

Send a request with ?locale=../../../config/database (adjust the number of ../ to reach the app root from the gem's locales/ directory).
Pagy calls YAML.load_file on the resulting …/config/database.yml.
The outcome differs by whether that .yml exists, is readable, parses as YAML, and has Pagy's expected structure — an existing, readable config/database.yml raises a different error than a non-existent path (which silently falls back to the default locale). This yields a file-existence / readability oracle for .yml paths, and the targeted file is read into the process during the attempt.

Impact

Information disclosure (CWE-22 / CWE-200): a file-existence / readability oracle for .yml paths on the host, plus a server-side read of attacker-chosen files into the process. The file contents are not returned in the response.

Only applications that pass unsanitized end-user input into Pagy::I18n.locale= are affected. Applications that set the locale from trusted values are not affected.

Patched: pagy 43.5.6. Workaround (if you cannot upgrade): validate the locale before assigning it, e.g. Pagy::I18n.locale = params[:locale].to_s[/\A[a-zA-Z]{2,8}(-[a-zA-Z0-9]{1,8})*\z/], or restrict it to your known set of locales.

Affected versions


          43.0.0


          43.0.1


          43.0.2


          43.0.3


          43.0.4


          43.0.5


          43.0.6


          43.0.7


          43.1.0


          43.1.1


          43.1.2


          43.1.3

+ 31 more


            43.1.4


            43.1.5


            43.1.6


            43.1.7


            43.1.8


            43.2.0


            43.2.1


            43.2.10


            43.2.2


            43.2.3


            43.2.4


            43.2.5


            43.2.6


            43.2.7


            43.2.8


            43.2.9


            43.3.0


            43.3.1


            43.3.2


            43.3.3


            43.4.0


            43.4.1


            43.4.2


            43.4.3


            43.4.4


            43.5.0


            43.5.1


            43.5.2


            43.5.3


            43.5.4


            43.5.5

Fixed in


          43.5.6

References

Updated Jul 28, 2026 · Source: OSV.dev

Mar 21, 2026

43.4.1 patch

1 CVE

CVE-2026-54659 GHSA-2xmw-f8j8-wfxc Jul 28, 2026

Pagy I18n locale option is not validated before being used in a file path

Medium

Network Low None None

Summary

Pagy::I18n.locale= did not validate its argument before using it as a path component to load the matching dictionary file (<locale>.yml). An application that assigns untrusted input to the locale — e.g. the common pattern Pagy::I18n.locale = params[:locale] — let that input influence which file Pagy attempted to load.

Details

The setter stored the value as-is, and the loader joined it into a path and read it:

# gem/lib/pagy/modules/i18n/i18n.rb
def locale=(value)
  Thread.current[:pagy_locale] = value.to_s
end

# ...later, when translating:
path = pathnames.reverse.map { |p| p.join("#{locale}.yml") }.find(&:exist?)
dictionary = YAML.load_file(path)[locale]

Because the locale was used verbatim, a value such as an absolute path or a ../-style string redirected the lookup outside the locales directory. Pagy's subsequent structural check (dictionary['pagy']['p11n']) prevents the file's contents from being returned, so this is not a direct file read.

Fixed in 43.5.6 by constraining the locale to a BCP 47 shape before use:

LOCALE_PATTERN = /\A[a-zA-Z]{2,8}(-[a-zA-Z0-9]{1,8})*\z/

def locale=(value)
  Thread.current[:pagy_locale] = value.to_s[LOCALE_PATTERN]
end

Any non-matching value (including nil) resolves to the default locale and never reaches the file lookup.

PoC

In an application that sets Pagy::I18n.locale = params[:locale], the loader appends .yml and reads <locale>.yml, so the request param controls the target path. For example, pointing it at the app's config/database.yml:

Send a request with ?locale=../../../config/database (adjust the number of ../ to reach the app root from the gem's locales/ directory).
Pagy calls YAML.load_file on the resulting …/config/database.yml.
The outcome differs by whether that .yml exists, is readable, parses as YAML, and has Pagy's expected structure — an existing, readable config/database.yml raises a different error than a non-existent path (which silently falls back to the default locale). This yields a file-existence / readability oracle for .yml paths, and the targeted file is read into the process during the attempt.

Impact

Information disclosure (CWE-22 / CWE-200): a file-existence / readability oracle for .yml paths on the host, plus a server-side read of attacker-chosen files into the process. The file contents are not returned in the response.

Only applications that pass unsanitized end-user input into Pagy::I18n.locale= are affected. Applications that set the locale from trusted values are not affected.

Patched: pagy 43.5.6. Workaround (if you cannot upgrade): validate the locale before assigning it, e.g. Pagy::I18n.locale = params[:locale].to_s[/\A[a-zA-Z]{2,8}(-[a-zA-Z0-9]{1,8})*\z/], or restrict it to your known set of locales.

Affected versions


          43.0.0


          43.0.1


          43.0.2


          43.0.3


          43.0.4


          43.0.5


          43.0.6


          43.0.7


          43.1.0


          43.1.1


          43.1.2


          43.1.3

+ 31 more


            43.1.4


            43.1.5


            43.1.6


            43.1.7


            43.1.8


            43.2.0


            43.2.1


            43.2.10


            43.2.2


            43.2.3


            43.2.4


            43.2.5


            43.2.6


            43.2.7


            43.2.8


            43.2.9


            43.3.0


            43.3.1


            43.3.2


            43.3.3


            43.4.0


            43.4.1


            43.4.2


            43.4.3


            43.4.4


            43.5.0


            43.5.1


            43.5.2


            43.5.3


            43.5.4


            43.5.5

Fixed in


          43.5.6

References

Updated Jul 28, 2026 · Source: OSV.dev

Mar 19, 2026

43.4.0 minor

1 CVE

CVE-2026-54659 GHSA-2xmw-f8j8-wfxc Jul 28, 2026

Pagy I18n locale option is not validated before being used in a file path

Medium

Network Low None None

Summary

Pagy::I18n.locale= did not validate its argument before using it as a path component to load the matching dictionary file (<locale>.yml). An application that assigns untrusted input to the locale — e.g. the common pattern Pagy::I18n.locale = params[:locale] — let that input influence which file Pagy attempted to load.

Details

The setter stored the value as-is, and the loader joined it into a path and read it:

# gem/lib/pagy/modules/i18n/i18n.rb
def locale=(value)
  Thread.current[:pagy_locale] = value.to_s
end

# ...later, when translating:
path = pathnames.reverse.map { |p| p.join("#{locale}.yml") }.find(&:exist?)
dictionary = YAML.load_file(path)[locale]

Because the locale was used verbatim, a value such as an absolute path or a ../-style string redirected the lookup outside the locales directory. Pagy's subsequent structural check (dictionary['pagy']['p11n']) prevents the file's contents from being returned, so this is not a direct file read.

Fixed in 43.5.6 by constraining the locale to a BCP 47 shape before use:

LOCALE_PATTERN = /\A[a-zA-Z]{2,8}(-[a-zA-Z0-9]{1,8})*\z/

def locale=(value)
  Thread.current[:pagy_locale] = value.to_s[LOCALE_PATTERN]
end

Any non-matching value (including nil) resolves to the default locale and never reaches the file lookup.

PoC

In an application that sets Pagy::I18n.locale = params[:locale], the loader appends .yml and reads <locale>.yml, so the request param controls the target path. For example, pointing it at the app's config/database.yml:

Send a request with ?locale=../../../config/database (adjust the number of ../ to reach the app root from the gem's locales/ directory).
Pagy calls YAML.load_file on the resulting …/config/database.yml.
The outcome differs by whether that .yml exists, is readable, parses as YAML, and has Pagy's expected structure — an existing, readable config/database.yml raises a different error than a non-existent path (which silently falls back to the default locale). This yields a file-existence / readability oracle for .yml paths, and the targeted file is read into the process during the attempt.

Impact

Information disclosure (CWE-22 / CWE-200): a file-existence / readability oracle for .yml paths on the host, plus a server-side read of attacker-chosen files into the process. The file contents are not returned in the response.

Only applications that pass unsanitized end-user input into Pagy::I18n.locale= are affected. Applications that set the locale from trusted values are not affected.

Patched: pagy 43.5.6. Workaround (if you cannot upgrade): validate the locale before assigning it, e.g. Pagy::I18n.locale = params[:locale].to_s[/\A[a-zA-Z]{2,8}(-[a-zA-Z0-9]{1,8})*\z/], or restrict it to your known set of locales.

Affected versions


          43.0.0


          43.0.1


          43.0.2


          43.0.3


          43.0.4


          43.0.5


          43.0.6


          43.0.7


          43.1.0


          43.1.1


          43.1.2


          43.1.3

+ 31 more


            43.1.4


            43.1.5


            43.1.6


            43.1.7


            43.1.8


            43.2.0


            43.2.1


            43.2.10


            43.2.2


            43.2.3


            43.2.4


            43.2.5


            43.2.6


            43.2.7


            43.2.8


            43.2.9


            43.3.0


            43.3.1


            43.3.2


            43.3.3


            43.4.0


            43.4.1


            43.4.2


            43.4.3


            43.4.4


            43.5.0


            43.5.1


            43.5.2


            43.5.3


            43.5.4


            43.5.5

Fixed in


          43.5.6

References

Updated Jul 28, 2026 · Source: OSV.dev

Mar 16, 2026

43.3.3 patch

1 CVE

CVE-2026-54659 GHSA-2xmw-f8j8-wfxc Jul 28, 2026

Pagy I18n locale option is not validated before being used in a file path

Medium

Network Low None None

Summary

Pagy::I18n.locale= did not validate its argument before using it as a path component to load the matching dictionary file (<locale>.yml). An application that assigns untrusted input to the locale — e.g. the common pattern Pagy::I18n.locale = params[:locale] — let that input influence which file Pagy attempted to load.

Details

The setter stored the value as-is, and the loader joined it into a path and read it:

# gem/lib/pagy/modules/i18n/i18n.rb
def locale=(value)
  Thread.current[:pagy_locale] = value.to_s
end

# ...later, when translating:
path = pathnames.reverse.map { |p| p.join("#{locale}.yml") }.find(&:exist?)
dictionary = YAML.load_file(path)[locale]

Because the locale was used verbatim, a value such as an absolute path or a ../-style string redirected the lookup outside the locales directory. Pagy's subsequent structural check (dictionary['pagy']['p11n']) prevents the file's contents from being returned, so this is not a direct file read.

Fixed in 43.5.6 by constraining the locale to a BCP 47 shape before use:

LOCALE_PATTERN = /\A[a-zA-Z]{2,8}(-[a-zA-Z0-9]{1,8})*\z/

def locale=(value)
  Thread.current[:pagy_locale] = value.to_s[LOCALE_PATTERN]
end

Any non-matching value (including nil) resolves to the default locale and never reaches the file lookup.

PoC

In an application that sets Pagy::I18n.locale = params[:locale], the loader appends .yml and reads <locale>.yml, so the request param controls the target path. For example, pointing it at the app's config/database.yml:

Send a request with ?locale=../../../config/database (adjust the number of ../ to reach the app root from the gem's locales/ directory).
Pagy calls YAML.load_file on the resulting …/config/database.yml.
The outcome differs by whether that .yml exists, is readable, parses as YAML, and has Pagy's expected structure — an existing, readable config/database.yml raises a different error than a non-existent path (which silently falls back to the default locale). This yields a file-existence / readability oracle for .yml paths, and the targeted file is read into the process during the attempt.

Impact

Information disclosure (CWE-22 / CWE-200): a file-existence / readability oracle for .yml paths on the host, plus a server-side read of attacker-chosen files into the process. The file contents are not returned in the response.

Only applications that pass unsanitized end-user input into Pagy::I18n.locale= are affected. Applications that set the locale from trusted values are not affected.

Patched: pagy 43.5.6. Workaround (if you cannot upgrade): validate the locale before assigning it, e.g. Pagy::I18n.locale = params[:locale].to_s[/\A[a-zA-Z]{2,8}(-[a-zA-Z0-9]{1,8})*\z/], or restrict it to your known set of locales.

Affected versions


          43.0.0


          43.0.1


          43.0.2


          43.0.3


          43.0.4


          43.0.5


          43.0.6


          43.0.7


          43.1.0


          43.1.1


          43.1.2


          43.1.3

+ 31 more


            43.1.4


            43.1.5


            43.1.6


            43.1.7


            43.1.8


            43.2.0


            43.2.1


            43.2.10


            43.2.2


            43.2.3


            43.2.4


            43.2.5


            43.2.6


            43.2.7


            43.2.8


            43.2.9


            43.3.0


            43.3.1


            43.3.2


            43.3.3


            43.4.0


            43.4.1


            43.4.2


            43.4.3


            43.4.4


            43.5.0


            43.5.1


            43.5.2


            43.5.3


            43.5.4


            43.5.5

Fixed in


          43.5.6

References

Updated Jul 28, 2026 · Source: OSV.dev

Mar 13, 2026

43.3.2 patch

1 CVE

CVE-2026-54659 GHSA-2xmw-f8j8-wfxc Jul 28, 2026

Pagy I18n locale option is not validated before being used in a file path

Medium

Network Low None None

Summary

Pagy::I18n.locale= did not validate its argument before using it as a path component to load the matching dictionary file (<locale>.yml). An application that assigns untrusted input to the locale — e.g. the common pattern Pagy::I18n.locale = params[:locale] — let that input influence which file Pagy attempted to load.

Details

The setter stored the value as-is, and the loader joined it into a path and read it:

# gem/lib/pagy/modules/i18n/i18n.rb
def locale=(value)
  Thread.current[:pagy_locale] = value.to_s
end

# ...later, when translating:
path = pathnames.reverse.map { |p| p.join("#{locale}.yml") }.find(&:exist?)
dictionary = YAML.load_file(path)[locale]

Because the locale was used verbatim, a value such as an absolute path or a ../-style string redirected the lookup outside the locales directory. Pagy's subsequent structural check (dictionary['pagy']['p11n']) prevents the file's contents from being returned, so this is not a direct file read.

Fixed in 43.5.6 by constraining the locale to a BCP 47 shape before use:

LOCALE_PATTERN = /\A[a-zA-Z]{2,8}(-[a-zA-Z0-9]{1,8})*\z/

def locale=(value)
  Thread.current[:pagy_locale] = value.to_s[LOCALE_PATTERN]
end

Any non-matching value (including nil) resolves to the default locale and never reaches the file lookup.

PoC

In an application that sets Pagy::I18n.locale = params[:locale], the loader appends .yml and reads <locale>.yml, so the request param controls the target path. For example, pointing it at the app's config/database.yml:

Send a request with ?locale=../../../config/database (adjust the number of ../ to reach the app root from the gem's locales/ directory).
Pagy calls YAML.load_file on the resulting …/config/database.yml.
The outcome differs by whether that .yml exists, is readable, parses as YAML, and has Pagy's expected structure — an existing, readable config/database.yml raises a different error than a non-existent path (which silently falls back to the default locale). This yields a file-existence / readability oracle for .yml paths, and the targeted file is read into the process during the attempt.

Impact

Information disclosure (CWE-22 / CWE-200): a file-existence / readability oracle for .yml paths on the host, plus a server-side read of attacker-chosen files into the process. The file contents are not returned in the response.

Only applications that pass unsanitized end-user input into Pagy::I18n.locale= are affected. Applications that set the locale from trusted values are not affected.

Patched: pagy 43.5.6. Workaround (if you cannot upgrade): validate the locale before assigning it, e.g. Pagy::I18n.locale = params[:locale].to_s[/\A[a-zA-Z]{2,8}(-[a-zA-Z0-9]{1,8})*\z/], or restrict it to your known set of locales.

Affected versions


          43.0.0


          43.0.1


          43.0.2


          43.0.3


          43.0.4


          43.0.5


          43.0.6


          43.0.7


          43.1.0


          43.1.1


          43.1.2


          43.1.3

+ 31 more


            43.1.4


            43.1.5


            43.1.6


            43.1.7


            43.1.8


            43.2.0


            43.2.1


            43.2.10


            43.2.2


            43.2.3


            43.2.4


            43.2.5


            43.2.6


            43.2.7


            43.2.8


            43.2.9


            43.3.0


            43.3.1


            43.3.2


            43.3.3


            43.4.0


            43.4.1


            43.4.2


            43.4.3


            43.4.4


            43.5.0


            43.5.1


            43.5.2


            43.5.3


            43.5.4


            43.5.5

Fixed in


          43.5.6

References

Updated Jul 28, 2026 · Source: OSV.dev

Mar 10, 2026

43.3.1 patch

1 CVE

CVE-2026-54659 GHSA-2xmw-f8j8-wfxc Jul 28, 2026

Pagy I18n locale option is not validated before being used in a file path

Medium

Network Low None None

Summary

Pagy::I18n.locale= did not validate its argument before using it as a path component to load the matching dictionary file (<locale>.yml). An application that assigns untrusted input to the locale — e.g. the common pattern Pagy::I18n.locale = params[:locale] — let that input influence which file Pagy attempted to load.

Details

The setter stored the value as-is, and the loader joined it into a path and read it:

# gem/lib/pagy/modules/i18n/i18n.rb
def locale=(value)
  Thread.current[:pagy_locale] = value.to_s
end

# ...later, when translating:
path = pathnames.reverse.map { |p| p.join("#{locale}.yml") }.find(&:exist?)
dictionary = YAML.load_file(path)[locale]

Because the locale was used verbatim, a value such as an absolute path or a ../-style string redirected the lookup outside the locales directory. Pagy's subsequent structural check (dictionary['pagy']['p11n']) prevents the file's contents from being returned, so this is not a direct file read.

Fixed in 43.5.6 by constraining the locale to a BCP 47 shape before use:

LOCALE_PATTERN = /\A[a-zA-Z]{2,8}(-[a-zA-Z0-9]{1,8})*\z/

def locale=(value)
  Thread.current[:pagy_locale] = value.to_s[LOCALE_PATTERN]
end

Any non-matching value (including nil) resolves to the default locale and never reaches the file lookup.

PoC

In an application that sets Pagy::I18n.locale = params[:locale], the loader appends .yml and reads <locale>.yml, so the request param controls the target path. For example, pointing it at the app's config/database.yml:

Send a request with ?locale=../../../config/database (adjust the number of ../ to reach the app root from the gem's locales/ directory).
Pagy calls YAML.load_file on the resulting …/config/database.yml.
The outcome differs by whether that .yml exists, is readable, parses as YAML, and has Pagy's expected structure — an existing, readable config/database.yml raises a different error than a non-existent path (which silently falls back to the default locale). This yields a file-existence / readability oracle for .yml paths, and the targeted file is read into the process during the attempt.

Impact

Information disclosure (CWE-22 / CWE-200): a file-existence / readability oracle for .yml paths on the host, plus a server-side read of attacker-chosen files into the process. The file contents are not returned in the response.

Only applications that pass unsanitized end-user input into Pagy::I18n.locale= are affected. Applications that set the locale from trusted values are not affected.

Patched: pagy 43.5.6. Workaround (if you cannot upgrade): validate the locale before assigning it, e.g. Pagy::I18n.locale = params[:locale].to_s[/\A[a-zA-Z]{2,8}(-[a-zA-Z0-9]{1,8})*\z/], or restrict it to your known set of locales.

Affected versions


          43.0.0


          43.0.1


          43.0.2


          43.0.3


          43.0.4


          43.0.5


          43.0.6


          43.0.7


          43.1.0


          43.1.1


          43.1.2


          43.1.3

+ 31 more


            43.1.4


            43.1.5


            43.1.6


            43.1.7


            43.1.8


            43.2.0


            43.2.1


            43.2.10


            43.2.2


            43.2.3


            43.2.4


            43.2.5


            43.2.6


            43.2.7


            43.2.8


            43.2.9


            43.3.0


            43.3.1


            43.3.2


            43.3.3


            43.4.0


            43.4.1


            43.4.2


            43.4.3


            43.4.4


            43.5.0


            43.5.1


            43.5.2


            43.5.3


            43.5.4


            43.5.5

Fixed in


          43.5.6

References

Updated Jul 28, 2026 · Source: OSV.dev

Feb 26, 2026

43.3.0 minor

1 CVE

CVE-2026-54659 GHSA-2xmw-f8j8-wfxc Jul 28, 2026

Pagy I18n locale option is not validated before being used in a file path

Medium

Network Low None None

Summary

Pagy::I18n.locale= did not validate its argument before using it as a path component to load the matching dictionary file (<locale>.yml). An application that assigns untrusted input to the locale — e.g. the common pattern Pagy::I18n.locale = params[:locale] — let that input influence which file Pagy attempted to load.

Details

The setter stored the value as-is, and the loader joined it into a path and read it:

# gem/lib/pagy/modules/i18n/i18n.rb
def locale=(value)
  Thread.current[:pagy_locale] = value.to_s
end

# ...later, when translating:
path = pathnames.reverse.map { |p| p.join("#{locale}.yml") }.find(&:exist?)
dictionary = YAML.load_file(path)[locale]

Because the locale was used verbatim, a value such as an absolute path or a ../-style string redirected the lookup outside the locales directory. Pagy's subsequent structural check (dictionary['pagy']['p11n']) prevents the file's contents from being returned, so this is not a direct file read.

Fixed in 43.5.6 by constraining the locale to a BCP 47 shape before use:

LOCALE_PATTERN = /\A[a-zA-Z]{2,8}(-[a-zA-Z0-9]{1,8})*\z/

def locale=(value)
  Thread.current[:pagy_locale] = value.to_s[LOCALE_PATTERN]
end

Any non-matching value (including nil) resolves to the default locale and never reaches the file lookup.

PoC

In an application that sets Pagy::I18n.locale = params[:locale], the loader appends .yml and reads <locale>.yml, so the request param controls the target path. For example, pointing it at the app's config/database.yml:

Send a request with ?locale=../../../config/database (adjust the number of ../ to reach the app root from the gem's locales/ directory).
Pagy calls YAML.load_file on the resulting …/config/database.yml.
The outcome differs by whether that .yml exists, is readable, parses as YAML, and has Pagy's expected structure — an existing, readable config/database.yml raises a different error than a non-existent path (which silently falls back to the default locale). This yields a file-existence / readability oracle for .yml paths, and the targeted file is read into the process during the attempt.

Impact

Information disclosure (CWE-22 / CWE-200): a file-existence / readability oracle for .yml paths on the host, plus a server-side read of attacker-chosen files into the process. The file contents are not returned in the response.

Only applications that pass unsanitized end-user input into Pagy::I18n.locale= are affected. Applications that set the locale from trusted values are not affected.

Patched: pagy 43.5.6. Workaround (if you cannot upgrade): validate the locale before assigning it, e.g. Pagy::I18n.locale = params[:locale].to_s[/\A[a-zA-Z]{2,8}(-[a-zA-Z0-9]{1,8})*\z/], or restrict it to your known set of locales.

Affected versions


          43.0.0


          43.0.1


          43.0.2


          43.0.3


          43.0.4


          43.0.5


          43.0.6


          43.0.7


          43.1.0


          43.1.1


          43.1.2


          43.1.3

+ 31 more


            43.1.4


            43.1.5


            43.1.6


            43.1.7


            43.1.8


            43.2.0


            43.2.1


            43.2.10


            43.2.2


            43.2.3


            43.2.4


            43.2.5


            43.2.6


            43.2.7


            43.2.8


            43.2.9


            43.3.0


            43.3.1


            43.3.2


            43.3.3


            43.4.0


            43.4.1


            43.4.2


            43.4.3


            43.4.4


            43.5.0


            43.5.1


            43.5.2


            43.5.3


            43.5.4


            43.5.5

Fixed in


          43.5.6

References

Updated Jul 28, 2026 · Source: OSV.dev

Feb 21, 2026

43.2.10 patch

1 CVE

CVE-2026-54659 GHSA-2xmw-f8j8-wfxc Jul 28, 2026

Pagy I18n locale option is not validated before being used in a file path

Medium

Network Low None None

Summary

Pagy::I18n.locale= did not validate its argument before using it as a path component to load the matching dictionary file (<locale>.yml). An application that assigns untrusted input to the locale — e.g. the common pattern Pagy::I18n.locale = params[:locale] — let that input influence which file Pagy attempted to load.

Details

The setter stored the value as-is, and the loader joined it into a path and read it:

# gem/lib/pagy/modules/i18n/i18n.rb
def locale=(value)
  Thread.current[:pagy_locale] = value.to_s
end

# ...later, when translating:
path = pathnames.reverse.map { |p| p.join("#{locale}.yml") }.find(&:exist?)
dictionary = YAML.load_file(path)[locale]

Because the locale was used verbatim, a value such as an absolute path or a ../-style string redirected the lookup outside the locales directory. Pagy's subsequent structural check (dictionary['pagy']['p11n']) prevents the file's contents from being returned, so this is not a direct file read.

Fixed in 43.5.6 by constraining the locale to a BCP 47 shape before use:

LOCALE_PATTERN = /\A[a-zA-Z]{2,8}(-[a-zA-Z0-9]{1,8})*\z/

def locale=(value)
  Thread.current[:pagy_locale] = value.to_s[LOCALE_PATTERN]
end

Any non-matching value (including nil) resolves to the default locale and never reaches the file lookup.

PoC

In an application that sets Pagy::I18n.locale = params[:locale], the loader appends .yml and reads <locale>.yml, so the request param controls the target path. For example, pointing it at the app's config/database.yml:

Send a request with ?locale=../../../config/database (adjust the number of ../ to reach the app root from the gem's locales/ directory).
Pagy calls YAML.load_file on the resulting …/config/database.yml.
The outcome differs by whether that .yml exists, is readable, parses as YAML, and has Pagy's expected structure — an existing, readable config/database.yml raises a different error than a non-existent path (which silently falls back to the default locale). This yields a file-existence / readability oracle for .yml paths, and the targeted file is read into the process during the attempt.

Impact

Information disclosure (CWE-22 / CWE-200): a file-existence / readability oracle for .yml paths on the host, plus a server-side read of attacker-chosen files into the process. The file contents are not returned in the response.

Only applications that pass unsanitized end-user input into Pagy::I18n.locale= are affected. Applications that set the locale from trusted values are not affected.

Patched: pagy 43.5.6. Workaround (if you cannot upgrade): validate the locale before assigning it, e.g. Pagy::I18n.locale = params[:locale].to_s[/\A[a-zA-Z]{2,8}(-[a-zA-Z0-9]{1,8})*\z/], or restrict it to your known set of locales.

Affected versions


          43.0.0


          43.0.1


          43.0.2


          43.0.3


          43.0.4


          43.0.5


          43.0.6


          43.0.7


          43.1.0


          43.1.1


          43.1.2


          43.1.3

+ 31 more


            43.1.4


            43.1.5


            43.1.6


            43.1.7


            43.1.8


            43.2.0


            43.2.1


            43.2.10


            43.2.2


            43.2.3


            43.2.4


            43.2.5


            43.2.6


            43.2.7


            43.2.8


            43.2.9


            43.3.0


            43.3.1


            43.3.2


            43.3.3


            43.4.0


            43.4.1


            43.4.2


            43.4.3


            43.4.4


            43.5.0


            43.5.1


            43.5.2


            43.5.3


            43.5.4


            43.5.5

Fixed in


          43.5.6

References

Updated Jul 28, 2026 · Source: OSV.dev

Feb 17, 2026

43.2.9 patch

1 CVE

CVE-2026-54659 GHSA-2xmw-f8j8-wfxc Jul 28, 2026

Pagy I18n locale option is not validated before being used in a file path

Medium

Network Low None None

Summary

Pagy::I18n.locale= did not validate its argument before using it as a path component to load the matching dictionary file (<locale>.yml). An application that assigns untrusted input to the locale — e.g. the common pattern Pagy::I18n.locale = params[:locale] — let that input influence which file Pagy attempted to load.

Details

The setter stored the value as-is, and the loader joined it into a path and read it:

# gem/lib/pagy/modules/i18n/i18n.rb
def locale=(value)
  Thread.current[:pagy_locale] = value.to_s
end

# ...later, when translating:
path = pathnames.reverse.map { |p| p.join("#{locale}.yml") }.find(&:exist?)
dictionary = YAML.load_file(path)[locale]

Because the locale was used verbatim, a value such as an absolute path or a ../-style string redirected the lookup outside the locales directory. Pagy's subsequent structural check (dictionary['pagy']['p11n']) prevents the file's contents from being returned, so this is not a direct file read.

Fixed in 43.5.6 by constraining the locale to a BCP 47 shape before use:

LOCALE_PATTERN = /\A[a-zA-Z]{2,8}(-[a-zA-Z0-9]{1,8})*\z/

def locale=(value)
  Thread.current[:pagy_locale] = value.to_s[LOCALE_PATTERN]
end

Any non-matching value (including nil) resolves to the default locale and never reaches the file lookup.

PoC

In an application that sets Pagy::I18n.locale = params[:locale], the loader appends .yml and reads <locale>.yml, so the request param controls the target path. For example, pointing it at the app's config/database.yml:

Send a request with ?locale=../../../config/database (adjust the number of ../ to reach the app root from the gem's locales/ directory).
Pagy calls YAML.load_file on the resulting …/config/database.yml.
The outcome differs by whether that .yml exists, is readable, parses as YAML, and has Pagy's expected structure — an existing, readable config/database.yml raises a different error than a non-existent path (which silently falls back to the default locale). This yields a file-existence / readability oracle for .yml paths, and the targeted file is read into the process during the attempt.

Impact

Information disclosure (CWE-22 / CWE-200): a file-existence / readability oracle for .yml paths on the host, plus a server-side read of attacker-chosen files into the process. The file contents are not returned in the response.

Only applications that pass unsanitized end-user input into Pagy::I18n.locale= are affected. Applications that set the locale from trusted values are not affected.

Patched: pagy 43.5.6. Workaround (if you cannot upgrade): validate the locale before assigning it, e.g. Pagy::I18n.locale = params[:locale].to_s[/\A[a-zA-Z]{2,8}(-[a-zA-Z0-9]{1,8})*\z/], or restrict it to your known set of locales.

Affected versions


          43.0.0


          43.0.1


          43.0.2


          43.0.3


          43.0.4


          43.0.5


          43.0.6


          43.0.7


          43.1.0


          43.1.1


          43.1.2


          43.1.3

+ 31 more


            43.1.4


            43.1.5


            43.1.6


            43.1.7


            43.1.8


            43.2.0


            43.2.1


            43.2.10


            43.2.2


            43.2.3


            43.2.4


            43.2.5


            43.2.6


            43.2.7


            43.2.8


            43.2.9


            43.3.0


            43.3.1


            43.3.2


            43.3.3


            43.4.0


            43.4.1


            43.4.2


            43.4.3


            43.4.4


            43.5.0


            43.5.1


            43.5.2


            43.5.3


            43.5.4


            43.5.5

Fixed in


          43.5.6

References

Updated Jul 28, 2026 · Source: OSV.dev

Feb 05, 2026

43.2.8 patch

1 CVE

CVE-2026-54659 GHSA-2xmw-f8j8-wfxc Jul 28, 2026

Pagy I18n locale option is not validated before being used in a file path

Medium

Network Low None None

Summary

Pagy::I18n.locale= did not validate its argument before using it as a path component to load the matching dictionary file (<locale>.yml). An application that assigns untrusted input to the locale — e.g. the common pattern Pagy::I18n.locale = params[:locale] — let that input influence which file Pagy attempted to load.

Details

The setter stored the value as-is, and the loader joined it into a path and read it:

# gem/lib/pagy/modules/i18n/i18n.rb
def locale=(value)
  Thread.current[:pagy_locale] = value.to_s
end

# ...later, when translating:
path = pathnames.reverse.map { |p| p.join("#{locale}.yml") }.find(&:exist?)
dictionary = YAML.load_file(path)[locale]

Because the locale was used verbatim, a value such as an absolute path or a ../-style string redirected the lookup outside the locales directory. Pagy's subsequent structural check (dictionary['pagy']['p11n']) prevents the file's contents from being returned, so this is not a direct file read.

Fixed in 43.5.6 by constraining the locale to a BCP 47 shape before use:

LOCALE_PATTERN = /\A[a-zA-Z]{2,8}(-[a-zA-Z0-9]{1,8})*\z/

def locale=(value)
  Thread.current[:pagy_locale] = value.to_s[LOCALE_PATTERN]
end

Any non-matching value (including nil) resolves to the default locale and never reaches the file lookup.

PoC

In an application that sets Pagy::I18n.locale = params[:locale], the loader appends .yml and reads <locale>.yml, so the request param controls the target path. For example, pointing it at the app's config/database.yml:

Send a request with ?locale=../../../config/database (adjust the number of ../ to reach the app root from the gem's locales/ directory).
Pagy calls YAML.load_file on the resulting …/config/database.yml.
The outcome differs by whether that .yml exists, is readable, parses as YAML, and has Pagy's expected structure — an existing, readable config/database.yml raises a different error than a non-existent path (which silently falls back to the default locale). This yields a file-existence / readability oracle for .yml paths, and the targeted file is read into the process during the attempt.

Impact

Information disclosure (CWE-22 / CWE-200): a file-existence / readability oracle for .yml paths on the host, plus a server-side read of attacker-chosen files into the process. The file contents are not returned in the response.

Only applications that pass unsanitized end-user input into Pagy::I18n.locale= are affected. Applications that set the locale from trusted values are not affected.

Patched: pagy 43.5.6. Workaround (if you cannot upgrade): validate the locale before assigning it, e.g. Pagy::I18n.locale = params[:locale].to_s[/\A[a-zA-Z]{2,8}(-[a-zA-Z0-9]{1,8})*\z/], or restrict it to your known set of locales.

Affected versions


          43.0.0


          43.0.1


          43.0.2


          43.0.3


          43.0.4


          43.0.5


          43.0.6


          43.0.7


          43.1.0


          43.1.1


          43.1.2


          43.1.3

+ 31 more


            43.1.4


            43.1.5


            43.1.6


            43.1.7


            43.1.8


            43.2.0


            43.2.1


            43.2.10


            43.2.2


            43.2.3


            43.2.4


            43.2.5


            43.2.6


            43.2.7


            43.2.8


            43.2.9


            43.3.0


            43.3.1


            43.3.2


            43.3.3


            43.4.0


            43.4.1


            43.4.2


            43.4.3


            43.4.4


            43.5.0


            43.5.1


            43.5.2


            43.5.3


            43.5.4


            43.5.5

Fixed in


          43.5.6

References

Updated Jul 28, 2026 · Source: OSV.dev

Jan 24, 2026

43.2.7 patch

1 CVE

CVE-2026-54659 GHSA-2xmw-f8j8-wfxc Jul 28, 2026

Pagy I18n locale option is not validated before being used in a file path

Medium

Network Low None None

Summary

Pagy::I18n.locale= did not validate its argument before using it as a path component to load the matching dictionary file (<locale>.yml). An application that assigns untrusted input to the locale — e.g. the common pattern Pagy::I18n.locale = params[:locale] — let that input influence which file Pagy attempted to load.

Details

The setter stored the value as-is, and the loader joined it into a path and read it:

# gem/lib/pagy/modules/i18n/i18n.rb
def locale=(value)
  Thread.current[:pagy_locale] = value.to_s
end

# ...later, when translating:
path = pathnames.reverse.map { |p| p.join("#{locale}.yml") }.find(&:exist?)
dictionary = YAML.load_file(path)[locale]

Because the locale was used verbatim, a value such as an absolute path or a ../-style string redirected the lookup outside the locales directory. Pagy's subsequent structural check (dictionary['pagy']['p11n']) prevents the file's contents from being returned, so this is not a direct file read.

Fixed in 43.5.6 by constraining the locale to a BCP 47 shape before use:

LOCALE_PATTERN = /\A[a-zA-Z]{2,8}(-[a-zA-Z0-9]{1,8})*\z/

def locale=(value)
  Thread.current[:pagy_locale] = value.to_s[LOCALE_PATTERN]
end

Any non-matching value (including nil) resolves to the default locale and never reaches the file lookup.

PoC

In an application that sets Pagy::I18n.locale = params[:locale], the loader appends .yml and reads <locale>.yml, so the request param controls the target path. For example, pointing it at the app's config/database.yml:

Send a request with ?locale=../../../config/database (adjust the number of ../ to reach the app root from the gem's locales/ directory).
Pagy calls YAML.load_file on the resulting …/config/database.yml.
The outcome differs by whether that .yml exists, is readable, parses as YAML, and has Pagy's expected structure — an existing, readable config/database.yml raises a different error than a non-existent path (which silently falls back to the default locale). This yields a file-existence / readability oracle for .yml paths, and the targeted file is read into the process during the attempt.

Impact

Information disclosure (CWE-22 / CWE-200): a file-existence / readability oracle for .yml paths on the host, plus a server-side read of attacker-chosen files into the process. The file contents are not returned in the response.

Only applications that pass unsanitized end-user input into Pagy::I18n.locale= are affected. Applications that set the locale from trusted values are not affected.

Patched: pagy 43.5.6. Workaround (if you cannot upgrade): validate the locale before assigning it, e.g. Pagy::I18n.locale = params[:locale].to_s[/\A[a-zA-Z]{2,8}(-[a-zA-Z0-9]{1,8})*\z/], or restrict it to your known set of locales.

Affected versions


          43.0.0


          43.0.1


          43.0.2


          43.0.3


          43.0.4


          43.0.5


          43.0.6


          43.0.7


          43.1.0


          43.1.1


          43.1.2


          43.1.3

+ 31 more


            43.1.4


            43.1.5


            43.1.6


            43.1.7


            43.1.8


            43.2.0


            43.2.1


            43.2.10


            43.2.2


            43.2.3


            43.2.4


            43.2.5


            43.2.6


            43.2.7


            43.2.8


            43.2.9


            43.3.0


            43.3.1


            43.3.2


            43.3.3


            43.4.0


            43.4.1


            43.4.2


            43.4.3


            43.4.4


            43.5.0


            43.5.1


            43.5.2


            43.5.3


            43.5.4


            43.5.5

Fixed in


          43.5.6

References

Updated Jul 28, 2026 · Source: OSV.dev

Jan 20, 2026

43.2.6 patch

1 CVE

CVE-2026-54659 GHSA-2xmw-f8j8-wfxc Jul 28, 2026

Pagy I18n locale option is not validated before being used in a file path

Medium

Network Low None None

Summary

Pagy::I18n.locale= did not validate its argument before using it as a path component to load the matching dictionary file (<locale>.yml). An application that assigns untrusted input to the locale — e.g. the common pattern Pagy::I18n.locale = params[:locale] — let that input influence which file Pagy attempted to load.

Details

The setter stored the value as-is, and the loader joined it into a path and read it:

# gem/lib/pagy/modules/i18n/i18n.rb
def locale=(value)
  Thread.current[:pagy_locale] = value.to_s
end

# ...later, when translating:
path = pathnames.reverse.map { |p| p.join("#{locale}.yml") }.find(&:exist?)
dictionary = YAML.load_file(path)[locale]

Because the locale was used verbatim, a value such as an absolute path or a ../-style string redirected the lookup outside the locales directory. Pagy's subsequent structural check (dictionary['pagy']['p11n']) prevents the file's contents from being returned, so this is not a direct file read.

Fixed in 43.5.6 by constraining the locale to a BCP 47 shape before use:

LOCALE_PATTERN = /\A[a-zA-Z]{2,8}(-[a-zA-Z0-9]{1,8})*\z/

def locale=(value)
  Thread.current[:pagy_locale] = value.to_s[LOCALE_PATTERN]
end

Any non-matching value (including nil) resolves to the default locale and never reaches the file lookup.

PoC

In an application that sets Pagy::I18n.locale = params[:locale], the loader appends .yml and reads <locale>.yml, so the request param controls the target path. For example, pointing it at the app's config/database.yml:

Send a request with ?locale=../../../config/database (adjust the number of ../ to reach the app root from the gem's locales/ directory).
Pagy calls YAML.load_file on the resulting …/config/database.yml.
The outcome differs by whether that .yml exists, is readable, parses as YAML, and has Pagy's expected structure — an existing, readable config/database.yml raises a different error than a non-existent path (which silently falls back to the default locale). This yields a file-existence / readability oracle for .yml paths, and the targeted file is read into the process during the attempt.

Impact

Information disclosure (CWE-22 / CWE-200): a file-existence / readability oracle for .yml paths on the host, plus a server-side read of attacker-chosen files into the process. The file contents are not returned in the response.

Only applications that pass unsanitized end-user input into Pagy::I18n.locale= are affected. Applications that set the locale from trusted values are not affected.

Patched: pagy 43.5.6. Workaround (if you cannot upgrade): validate the locale before assigning it, e.g. Pagy::I18n.locale = params[:locale].to_s[/\A[a-zA-Z]{2,8}(-[a-zA-Z0-9]{1,8})*\z/], or restrict it to your known set of locales.

Affected versions


          43.0.0


          43.0.1


          43.0.2


          43.0.3


          43.0.4


          43.0.5


          43.0.6


          43.0.7


          43.1.0


          43.1.1


          43.1.2


          43.1.3

+ 31 more


            43.1.4


            43.1.5


            43.1.6


            43.1.7


            43.1.8


            43.2.0


            43.2.1


            43.2.10


            43.2.2


            43.2.3


            43.2.4


            43.2.5


            43.2.6


            43.2.7


            43.2.8


            43.2.9


            43.3.0


            43.3.1


            43.3.2


            43.3.3


            43.4.0


            43.4.1


            43.4.2


            43.4.3


            43.4.4


            43.5.0


            43.5.1


            43.5.2


            43.5.3


            43.5.4


            43.5.5

Fixed in


          43.5.6

References

Updated Jul 28, 2026 · Source: OSV.dev

Jan 16, 2026

43.2.5 patch

1 CVE

CVE-2026-54659 GHSA-2xmw-f8j8-wfxc Jul 28, 2026

Pagy I18n locale option is not validated before being used in a file path

Medium

Network Low None None

Summary

Pagy::I18n.locale= did not validate its argument before using it as a path component to load the matching dictionary file (<locale>.yml). An application that assigns untrusted input to the locale — e.g. the common pattern Pagy::I18n.locale = params[:locale] — let that input influence which file Pagy attempted to load.

Details

The setter stored the value as-is, and the loader joined it into a path and read it:

# gem/lib/pagy/modules/i18n/i18n.rb
def locale=(value)
  Thread.current[:pagy_locale] = value.to_s
end

# ...later, when translating:
path = pathnames.reverse.map { |p| p.join("#{locale}.yml") }.find(&:exist?)
dictionary = YAML.load_file(path)[locale]

Because the locale was used verbatim, a value such as an absolute path or a ../-style string redirected the lookup outside the locales directory. Pagy's subsequent structural check (dictionary['pagy']['p11n']) prevents the file's contents from being returned, so this is not a direct file read.

Fixed in 43.5.6 by constraining the locale to a BCP 47 shape before use:

LOCALE_PATTERN = /\A[a-zA-Z]{2,8}(-[a-zA-Z0-9]{1,8})*\z/

def locale=(value)
  Thread.current[:pagy_locale] = value.to_s[LOCALE_PATTERN]
end

Any non-matching value (including nil) resolves to the default locale and never reaches the file lookup.

PoC

In an application that sets Pagy::I18n.locale = params[:locale], the loader appends .yml and reads <locale>.yml, so the request param controls the target path. For example, pointing it at the app's config/database.yml:

Send a request with ?locale=../../../config/database (adjust the number of ../ to reach the app root from the gem's locales/ directory).
Pagy calls YAML.load_file on the resulting …/config/database.yml.
The outcome differs by whether that .yml exists, is readable, parses as YAML, and has Pagy's expected structure — an existing, readable config/database.yml raises a different error than a non-existent path (which silently falls back to the default locale). This yields a file-existence / readability oracle for .yml paths, and the targeted file is read into the process during the attempt.

Impact

Information disclosure (CWE-22 / CWE-200): a file-existence / readability oracle for .yml paths on the host, plus a server-side read of attacker-chosen files into the process. The file contents are not returned in the response.

Only applications that pass unsanitized end-user input into Pagy::I18n.locale= are affected. Applications that set the locale from trusted values are not affected.

Patched: pagy 43.5.6. Workaround (if you cannot upgrade): validate the locale before assigning it, e.g. Pagy::I18n.locale = params[:locale].to_s[/\A[a-zA-Z]{2,8}(-[a-zA-Z0-9]{1,8})*\z/], or restrict it to your known set of locales.

Affected versions


          43.0.0


          43.0.1


          43.0.2


          43.0.3


          43.0.4


          43.0.5


          43.0.6


          43.0.7


          43.1.0


          43.1.1


          43.1.2


          43.1.3

+ 31 more


            43.1.4


            43.1.5


            43.1.6


            43.1.7


            43.1.8


            43.2.0


            43.2.1


            43.2.10


            43.2.2


            43.2.3


            43.2.4


            43.2.5


            43.2.6


            43.2.7


            43.2.8


            43.2.9


            43.3.0


            43.3.1


            43.3.2


            43.3.3


            43.4.0


            43.4.1


            43.4.2


            43.4.3


            43.4.4


            43.5.0


            43.5.1


            43.5.2


            43.5.3


            43.5.4


            43.5.5

Fixed in


          43.5.6

References

Updated Jul 28, 2026 · Source: OSV.dev

Jan 16, 2026

43.2.4 patch

1 CVE

CVE-2026-54659 GHSA-2xmw-f8j8-wfxc Jul 28, 2026

Pagy I18n locale option is not validated before being used in a file path

Medium

Network Low None None

Summary

Pagy::I18n.locale= did not validate its argument before using it as a path component to load the matching dictionary file (<locale>.yml). An application that assigns untrusted input to the locale — e.g. the common pattern Pagy::I18n.locale = params[:locale] — let that input influence which file Pagy attempted to load.

Details

The setter stored the value as-is, and the loader joined it into a path and read it:

# gem/lib/pagy/modules/i18n/i18n.rb
def locale=(value)
  Thread.current[:pagy_locale] = value.to_s
end

# ...later, when translating:
path = pathnames.reverse.map { |p| p.join("#{locale}.yml") }.find(&:exist?)
dictionary = YAML.load_file(path)[locale]

Because the locale was used verbatim, a value such as an absolute path or a ../-style string redirected the lookup outside the locales directory. Pagy's subsequent structural check (dictionary['pagy']['p11n']) prevents the file's contents from being returned, so this is not a direct file read.

Fixed in 43.5.6 by constraining the locale to a BCP 47 shape before use:

LOCALE_PATTERN = /\A[a-zA-Z]{2,8}(-[a-zA-Z0-9]{1,8})*\z/

def locale=(value)
  Thread.current[:pagy_locale] = value.to_s[LOCALE_PATTERN]
end

Any non-matching value (including nil) resolves to the default locale and never reaches the file lookup.

PoC

In an application that sets Pagy::I18n.locale = params[:locale], the loader appends .yml and reads <locale>.yml, so the request param controls the target path. For example, pointing it at the app's config/database.yml:

Send a request with ?locale=../../../config/database (adjust the number of ../ to reach the app root from the gem's locales/ directory).
Pagy calls YAML.load_file on the resulting …/config/database.yml.
The outcome differs by whether that .yml exists, is readable, parses as YAML, and has Pagy's expected structure — an existing, readable config/database.yml raises a different error than a non-existent path (which silently falls back to the default locale). This yields a file-existence / readability oracle for .yml paths, and the targeted file is read into the process during the attempt.

Impact

Information disclosure (CWE-22 / CWE-200): a file-existence / readability oracle for .yml paths on the host, plus a server-side read of attacker-chosen files into the process. The file contents are not returned in the response.

Only applications that pass unsanitized end-user input into Pagy::I18n.locale= are affected. Applications that set the locale from trusted values are not affected.

Patched: pagy 43.5.6. Workaround (if you cannot upgrade): validate the locale before assigning it, e.g. Pagy::I18n.locale = params[:locale].to_s[/\A[a-zA-Z]{2,8}(-[a-zA-Z0-9]{1,8})*\z/], or restrict it to your known set of locales.

Affected versions


          43.0.0


          43.0.1


          43.0.2


          43.0.3


          43.0.4


          43.0.5


          43.0.6


          43.0.7


          43.1.0


          43.1.1


          43.1.2


          43.1.3

+ 31 more


            43.1.4


            43.1.5


            43.1.6


            43.1.7


            43.1.8


            43.2.0


            43.2.1


            43.2.10


            43.2.2


            43.2.3


            43.2.4


            43.2.5


            43.2.6


            43.2.7


            43.2.8


            43.2.9


            43.3.0


            43.3.1


            43.3.2


            43.3.3


            43.4.0


            43.4.1


            43.4.2


            43.4.3


            43.4.4


            43.5.0


            43.5.1


            43.5.2


            43.5.3


            43.5.4


            43.5.5

Fixed in


          43.5.6

References

Updated Jul 28, 2026 · Source: OSV.dev

Jan 13, 2026

43.2.3 patch

1 CVE

CVE-2026-54659 GHSA-2xmw-f8j8-wfxc Jul 28, 2026

Pagy I18n locale option is not validated before being used in a file path

Medium

Network Low None None

Summary

Pagy::I18n.locale= did not validate its argument before using it as a path component to load the matching dictionary file (<locale>.yml). An application that assigns untrusted input to the locale — e.g. the common pattern Pagy::I18n.locale = params[:locale] — let that input influence which file Pagy attempted to load.

Details

The setter stored the value as-is, and the loader joined it into a path and read it:

# gem/lib/pagy/modules/i18n/i18n.rb
def locale=(value)
  Thread.current[:pagy_locale] = value.to_s
end

# ...later, when translating:
path = pathnames.reverse.map { |p| p.join("#{locale}.yml") }.find(&:exist?)
dictionary = YAML.load_file(path)[locale]

Because the locale was used verbatim, a value such as an absolute path or a ../-style string redirected the lookup outside the locales directory. Pagy's subsequent structural check (dictionary['pagy']['p11n']) prevents the file's contents from being returned, so this is not a direct file read.

Fixed in 43.5.6 by constraining the locale to a BCP 47 shape before use:

LOCALE_PATTERN = /\A[a-zA-Z]{2,8}(-[a-zA-Z0-9]{1,8})*\z/

def locale=(value)
  Thread.current[:pagy_locale] = value.to_s[LOCALE_PATTERN]
end

Any non-matching value (including nil) resolves to the default locale and never reaches the file lookup.

PoC

In an application that sets Pagy::I18n.locale = params[:locale], the loader appends .yml and reads <locale>.yml, so the request param controls the target path. For example, pointing it at the app's config/database.yml:

Send a request with ?locale=../../../config/database (adjust the number of ../ to reach the app root from the gem's locales/ directory).
Pagy calls YAML.load_file on the resulting …/config/database.yml.
The outcome differs by whether that .yml exists, is readable, parses as YAML, and has Pagy's expected structure — an existing, readable config/database.yml raises a different error than a non-existent path (which silently falls back to the default locale). This yields a file-existence / readability oracle for .yml paths, and the targeted file is read into the process during the attempt.

Impact

Information disclosure (CWE-22 / CWE-200): a file-existence / readability oracle for .yml paths on the host, plus a server-side read of attacker-chosen files into the process. The file contents are not returned in the response.

Only applications that pass unsanitized end-user input into Pagy::I18n.locale= are affected. Applications that set the locale from trusted values are not affected.

Patched: pagy 43.5.6. Workaround (if you cannot upgrade): validate the locale before assigning it, e.g. Pagy::I18n.locale = params[:locale].to_s[/\A[a-zA-Z]{2,8}(-[a-zA-Z0-9]{1,8})*\z/], or restrict it to your known set of locales.

Affected versions


          43.0.0


          43.0.1


          43.0.2


          43.0.3


          43.0.4


          43.0.5


          43.0.6


          43.0.7


          43.1.0


          43.1.1


          43.1.2


          43.1.3

+ 31 more


            43.1.4


            43.1.5


            43.1.6


            43.1.7


            43.1.8


            43.2.0


            43.2.1


            43.2.10


            43.2.2


            43.2.3


            43.2.4


            43.2.5


            43.2.6


            43.2.7


            43.2.8


            43.2.9


            43.3.0


            43.3.1


            43.3.2


            43.3.3


            43.4.0


            43.4.1


            43.4.2


            43.4.3


            43.4.4


            43.5.0


            43.5.1


            43.5.2


            43.5.3


            43.5.4


            43.5.5

Fixed in


          43.5.6

References

Updated Jul 28, 2026 · Source: OSV.dev

Jan 10, 2026

43.2.2 patch

1 CVE

CVE-2026-54659 GHSA-2xmw-f8j8-wfxc Jul 28, 2026

Pagy I18n locale option is not validated before being used in a file path

Medium

Network Low None None

Summary

Pagy::I18n.locale= did not validate its argument before using it as a path component to load the matching dictionary file (<locale>.yml). An application that assigns untrusted input to the locale — e.g. the common pattern Pagy::I18n.locale = params[:locale] — let that input influence which file Pagy attempted to load.

Details

The setter stored the value as-is, and the loader joined it into a path and read it:

# gem/lib/pagy/modules/i18n/i18n.rb
def locale=(value)
  Thread.current[:pagy_locale] = value.to_s
end

# ...later, when translating:
path = pathnames.reverse.map { |p| p.join("#{locale}.yml") }.find(&:exist?)
dictionary = YAML.load_file(path)[locale]

Because the locale was used verbatim, a value such as an absolute path or a ../-style string redirected the lookup outside the locales directory. Pagy's subsequent structural check (dictionary['pagy']['p11n']) prevents the file's contents from being returned, so this is not a direct file read.

Fixed in 43.5.6 by constraining the locale to a BCP 47 shape before use:

LOCALE_PATTERN = /\A[a-zA-Z]{2,8}(-[a-zA-Z0-9]{1,8})*\z/

def locale=(value)
  Thread.current[:pagy_locale] = value.to_s[LOCALE_PATTERN]
end

Any non-matching value (including nil) resolves to the default locale and never reaches the file lookup.

PoC

In an application that sets Pagy::I18n.locale = params[:locale], the loader appends .yml and reads <locale>.yml, so the request param controls the target path. For example, pointing it at the app's config/database.yml:

Send a request with ?locale=../../../config/database (adjust the number of ../ to reach the app root from the gem's locales/ directory).
Pagy calls YAML.load_file on the resulting …/config/database.yml.
The outcome differs by whether that .yml exists, is readable, parses as YAML, and has Pagy's expected structure — an existing, readable config/database.yml raises a different error than a non-existent path (which silently falls back to the default locale). This yields a file-existence / readability oracle for .yml paths, and the targeted file is read into the process during the attempt.

Impact

Information disclosure (CWE-22 / CWE-200): a file-existence / readability oracle for .yml paths on the host, plus a server-side read of attacker-chosen files into the process. The file contents are not returned in the response.

Only applications that pass unsanitized end-user input into Pagy::I18n.locale= are affected. Applications that set the locale from trusted values are not affected.

Patched: pagy 43.5.6. Workaround (if you cannot upgrade): validate the locale before assigning it, e.g. Pagy::I18n.locale = params[:locale].to_s[/\A[a-zA-Z]{2,8}(-[a-zA-Z0-9]{1,8})*\z/], or restrict it to your known set of locales.

Affected versions


          43.0.0


          43.0.1


          43.0.2


          43.0.3


          43.0.4


          43.0.5


          43.0.6


          43.0.7


          43.1.0


          43.1.1


          43.1.2


          43.1.3

+ 31 more


            43.1.4


            43.1.5


            43.1.6


            43.1.7


            43.1.8


            43.2.0


            43.2.1


            43.2.10


            43.2.2


            43.2.3


            43.2.4


            43.2.5


            43.2.6


            43.2.7


            43.2.8


            43.2.9


            43.3.0


            43.3.1


            43.3.2


            43.3.3


            43.4.0


            43.4.1


            43.4.2


            43.4.3


            43.4.4


            43.5.0


            43.5.1


            43.5.2


            43.5.3


            43.5.4


            43.5.5

Fixed in


          43.5.6

References

Updated Jul 28, 2026 · Source: OSV.dev

Dec 18, 2025

43.2.1 patch

1 CVE

CVE-2026-54659 GHSA-2xmw-f8j8-wfxc Jul 28, 2026

Pagy I18n locale option is not validated before being used in a file path

Medium

Network Low None None

Summary

Pagy::I18n.locale= did not validate its argument before using it as a path component to load the matching dictionary file (<locale>.yml). An application that assigns untrusted input to the locale — e.g. the common pattern Pagy::I18n.locale = params[:locale] — let that input influence which file Pagy attempted to load.

Details

The setter stored the value as-is, and the loader joined it into a path and read it:

# gem/lib/pagy/modules/i18n/i18n.rb
def locale=(value)
  Thread.current[:pagy_locale] = value.to_s
end

# ...later, when translating:
path = pathnames.reverse.map { |p| p.join("#{locale}.yml") }.find(&:exist?)
dictionary = YAML.load_file(path)[locale]

Because the locale was used verbatim, a value such as an absolute path or a ../-style string redirected the lookup outside the locales directory. Pagy's subsequent structural check (dictionary['pagy']['p11n']) prevents the file's contents from being returned, so this is not a direct file read.

Fixed in 43.5.6 by constraining the locale to a BCP 47 shape before use:

LOCALE_PATTERN = /\A[a-zA-Z]{2,8}(-[a-zA-Z0-9]{1,8})*\z/

def locale=(value)
  Thread.current[:pagy_locale] = value.to_s[LOCALE_PATTERN]
end

Any non-matching value (including nil) resolves to the default locale and never reaches the file lookup.

PoC

In an application that sets Pagy::I18n.locale = params[:locale], the loader appends .yml and reads <locale>.yml, so the request param controls the target path. For example, pointing it at the app's config/database.yml:

Send a request with ?locale=../../../config/database (adjust the number of ../ to reach the app root from the gem's locales/ directory).
Pagy calls YAML.load_file on the resulting …/config/database.yml.
The outcome differs by whether that .yml exists, is readable, parses as YAML, and has Pagy's expected structure — an existing, readable config/database.yml raises a different error than a non-existent path (which silently falls back to the default locale). This yields a file-existence / readability oracle for .yml paths, and the targeted file is read into the process during the attempt.

Impact

Information disclosure (CWE-22 / CWE-200): a file-existence / readability oracle for .yml paths on the host, plus a server-side read of attacker-chosen files into the process. The file contents are not returned in the response.

Only applications that pass unsanitized end-user input into Pagy::I18n.locale= are affected. Applications that set the locale from trusted values are not affected.

Patched: pagy 43.5.6. Workaround (if you cannot upgrade): validate the locale before assigning it, e.g. Pagy::I18n.locale = params[:locale].to_s[/\A[a-zA-Z]{2,8}(-[a-zA-Z0-9]{1,8})*\z/], or restrict it to your known set of locales.

Affected versions


          43.0.0


          43.0.1


          43.0.2


          43.0.3


          43.0.4


          43.0.5


          43.0.6


          43.0.7


          43.1.0


          43.1.1


          43.1.2


          43.1.3

+ 31 more


            43.1.4


            43.1.5


            43.1.6


            43.1.7


            43.1.8


            43.2.0


            43.2.1


            43.2.10


            43.2.2


            43.2.3


            43.2.4


            43.2.5


            43.2.6


            43.2.7


            43.2.8


            43.2.9


            43.3.0


            43.3.1


            43.3.2


            43.3.3


            43.4.0


            43.4.1


            43.4.2


            43.4.3


            43.4.4


            43.5.0


            43.5.1


            43.5.2


            43.5.3


            43.5.4


            43.5.5

Fixed in


          43.5.6

References

Updated Jul 28, 2026 · Source: OSV.dev

Dec 14, 2025

43.2.0 minor

1 CVE

CVE-2026-54659 GHSA-2xmw-f8j8-wfxc Jul 28, 2026

Pagy I18n locale option is not validated before being used in a file path

Medium

Network Low None None

Summary

Pagy::I18n.locale= did not validate its argument before using it as a path component to load the matching dictionary file (<locale>.yml). An application that assigns untrusted input to the locale — e.g. the common pattern Pagy::I18n.locale = params[:locale] — let that input influence which file Pagy attempted to load.

Details

The setter stored the value as-is, and the loader joined it into a path and read it:

# gem/lib/pagy/modules/i18n/i18n.rb
def locale=(value)
  Thread.current[:pagy_locale] = value.to_s
end

# ...later, when translating:
path = pathnames.reverse.map { |p| p.join("#{locale}.yml") }.find(&:exist?)
dictionary = YAML.load_file(path)[locale]

Because the locale was used verbatim, a value such as an absolute path or a ../-style string redirected the lookup outside the locales directory. Pagy's subsequent structural check (dictionary['pagy']['p11n']) prevents the file's contents from being returned, so this is not a direct file read.

Fixed in 43.5.6 by constraining the locale to a BCP 47 shape before use:

LOCALE_PATTERN = /\A[a-zA-Z]{2,8}(-[a-zA-Z0-9]{1,8})*\z/

def locale=(value)
  Thread.current[:pagy_locale] = value.to_s[LOCALE_PATTERN]
end

Any non-matching value (including nil) resolves to the default locale and never reaches the file lookup.

PoC

In an application that sets Pagy::I18n.locale = params[:locale], the loader appends .yml and reads <locale>.yml, so the request param controls the target path. For example, pointing it at the app's config/database.yml:

Send a request with ?locale=../../../config/database (adjust the number of ../ to reach the app root from the gem's locales/ directory).
Pagy calls YAML.load_file on the resulting …/config/database.yml.
The outcome differs by whether that .yml exists, is readable, parses as YAML, and has Pagy's expected structure — an existing, readable config/database.yml raises a different error than a non-existent path (which silently falls back to the default locale). This yields a file-existence / readability oracle for .yml paths, and the targeted file is read into the process during the attempt.

Impact

Information disclosure (CWE-22 / CWE-200): a file-existence / readability oracle for .yml paths on the host, plus a server-side read of attacker-chosen files into the process. The file contents are not returned in the response.

Only applications that pass unsanitized end-user input into Pagy::I18n.locale= are affected. Applications that set the locale from trusted values are not affected.

Patched: pagy 43.5.6. Workaround (if you cannot upgrade): validate the locale before assigning it, e.g. Pagy::I18n.locale = params[:locale].to_s[/\A[a-zA-Z]{2,8}(-[a-zA-Z0-9]{1,8})*\z/], or restrict it to your known set of locales.

Affected versions


          43.0.0


          43.0.1


          43.0.2


          43.0.3


          43.0.4


          43.0.5


          43.0.6


          43.0.7


          43.1.0


          43.1.1


          43.1.2


          43.1.3

+ 31 more


            43.1.4


            43.1.5


            43.1.6


            43.1.7


            43.1.8


            43.2.0


            43.2.1


            43.2.10


            43.2.2


            43.2.3


            43.2.4


            43.2.5


            43.2.6


            43.2.7


            43.2.8


            43.2.9


            43.3.0


            43.3.1


            43.3.2


            43.3.3


            43.4.0


            43.4.1


            43.4.2


            43.4.3


            43.4.4


            43.5.0


            43.5.1


            43.5.2


            43.5.3


            43.5.4


            43.5.5

Fixed in


          43.5.6

References

Updated Jul 28, 2026 · Source: OSV.dev

Dec 04, 2025

43.1.8 patch

1 CVE

CVE-2026-54659 GHSA-2xmw-f8j8-wfxc Jul 28, 2026

Pagy I18n locale option is not validated before being used in a file path

Medium

Network Low None None

Summary

Pagy::I18n.locale= did not validate its argument before using it as a path component to load the matching dictionary file (<locale>.yml). An application that assigns untrusted input to the locale — e.g. the common pattern Pagy::I18n.locale = params[:locale] — let that input influence which file Pagy attempted to load.

Details

The setter stored the value as-is, and the loader joined it into a path and read it:

# gem/lib/pagy/modules/i18n/i18n.rb
def locale=(value)
  Thread.current[:pagy_locale] = value.to_s
end

# ...later, when translating:
path = pathnames.reverse.map { |p| p.join("#{locale}.yml") }.find(&:exist?)
dictionary = YAML.load_file(path)[locale]

Because the locale was used verbatim, a value such as an absolute path or a ../-style string redirected the lookup outside the locales directory. Pagy's subsequent structural check (dictionary['pagy']['p11n']) prevents the file's contents from being returned, so this is not a direct file read.

Fixed in 43.5.6 by constraining the locale to a BCP 47 shape before use:

LOCALE_PATTERN = /\A[a-zA-Z]{2,8}(-[a-zA-Z0-9]{1,8})*\z/

def locale=(value)
  Thread.current[:pagy_locale] = value.to_s[LOCALE_PATTERN]
end

Any non-matching value (including nil) resolves to the default locale and never reaches the file lookup.

PoC

In an application that sets Pagy::I18n.locale = params[:locale], the loader appends .yml and reads <locale>.yml, so the request param controls the target path. For example, pointing it at the app's config/database.yml:

Send a request with ?locale=../../../config/database (adjust the number of ../ to reach the app root from the gem's locales/ directory).
Pagy calls YAML.load_file on the resulting …/config/database.yml.
The outcome differs by whether that .yml exists, is readable, parses as YAML, and has Pagy's expected structure — an existing, readable config/database.yml raises a different error than a non-existent path (which silently falls back to the default locale). This yields a file-existence / readability oracle for .yml paths, and the targeted file is read into the process during the attempt.

Impact

Information disclosure (CWE-22 / CWE-200): a file-existence / readability oracle for .yml paths on the host, plus a server-side read of attacker-chosen files into the process. The file contents are not returned in the response.

Only applications that pass unsanitized end-user input into Pagy::I18n.locale= are affected. Applications that set the locale from trusted values are not affected.

Patched: pagy 43.5.6. Workaround (if you cannot upgrade): validate the locale before assigning it, e.g. Pagy::I18n.locale = params[:locale].to_s[/\A[a-zA-Z]{2,8}(-[a-zA-Z0-9]{1,8})*\z/], or restrict it to your known set of locales.

Affected versions


          43.0.0


          43.0.1


          43.0.2


          43.0.3


          43.0.4


          43.0.5


          43.0.6


          43.0.7


          43.1.0


          43.1.1


          43.1.2


          43.1.3

+ 31 more


            43.1.4


            43.1.5


            43.1.6


            43.1.7


            43.1.8


            43.2.0


            43.2.1


            43.2.10


            43.2.2


            43.2.3


            43.2.4


            43.2.5


            43.2.6


            43.2.7


            43.2.8


            43.2.9


            43.3.0


            43.3.1


            43.3.2


            43.3.3


            43.4.0


            43.4.1


            43.4.2


            43.4.3


            43.4.4


            43.5.0


            43.5.1


            43.5.2


            43.5.3


            43.5.4


            43.5.5

Fixed in


          43.5.6

References

Updated Jul 28, 2026 · Source: OSV.dev

Nov 28, 2025

43.1.7 patch

1 CVE

CVE-2026-54659 GHSA-2xmw-f8j8-wfxc Jul 28, 2026

Pagy I18n locale option is not validated before being used in a file path

Medium

Network Low None None

Summary

Pagy::I18n.locale= did not validate its argument before using it as a path component to load the matching dictionary file (<locale>.yml). An application that assigns untrusted input to the locale — e.g. the common pattern Pagy::I18n.locale = params[:locale] — let that input influence which file Pagy attempted to load.

Details

The setter stored the value as-is, and the loader joined it into a path and read it:

# gem/lib/pagy/modules/i18n/i18n.rb
def locale=(value)
  Thread.current[:pagy_locale] = value.to_s
end

# ...later, when translating:
path = pathnames.reverse.map { |p| p.join("#{locale}.yml") }.find(&:exist?)
dictionary = YAML.load_file(path)[locale]

Because the locale was used verbatim, a value such as an absolute path or a ../-style string redirected the lookup outside the locales directory. Pagy's subsequent structural check (dictionary['pagy']['p11n']) prevents the file's contents from being returned, so this is not a direct file read.

Fixed in 43.5.6 by constraining the locale to a BCP 47 shape before use:

LOCALE_PATTERN = /\A[a-zA-Z]{2,8}(-[a-zA-Z0-9]{1,8})*\z/

def locale=(value)
  Thread.current[:pagy_locale] = value.to_s[LOCALE_PATTERN]
end

Any non-matching value (including nil) resolves to the default locale and never reaches the file lookup.

PoC

In an application that sets Pagy::I18n.locale = params[:locale], the loader appends .yml and reads <locale>.yml, so the request param controls the target path. For example, pointing it at the app's config/database.yml:

Send a request with ?locale=../../../config/database (adjust the number of ../ to reach the app root from the gem's locales/ directory).
Pagy calls YAML.load_file on the resulting …/config/database.yml.
The outcome differs by whether that .yml exists, is readable, parses as YAML, and has Pagy's expected structure — an existing, readable config/database.yml raises a different error than a non-existent path (which silently falls back to the default locale). This yields a file-existence / readability oracle for .yml paths, and the targeted file is read into the process during the attempt.

Impact

Information disclosure (CWE-22 / CWE-200): a file-existence / readability oracle for .yml paths on the host, plus a server-side read of attacker-chosen files into the process. The file contents are not returned in the response.

Only applications that pass unsanitized end-user input into Pagy::I18n.locale= are affected. Applications that set the locale from trusted values are not affected.

Patched: pagy 43.5.6. Workaround (if you cannot upgrade): validate the locale before assigning it, e.g. Pagy::I18n.locale = params[:locale].to_s[/\A[a-zA-Z]{2,8}(-[a-zA-Z0-9]{1,8})*\z/], or restrict it to your known set of locales.

Affected versions


          43.0.0


          43.0.1


          43.0.2


          43.0.3


          43.0.4


          43.0.5


          43.0.6


          43.0.7


          43.1.0


          43.1.1


          43.1.2


          43.1.3

+ 31 more


            43.1.4


            43.1.5


            43.1.6


            43.1.7


            43.1.8


            43.2.0


            43.2.1


            43.2.10


            43.2.2


            43.2.3


            43.2.4


            43.2.5


            43.2.6


            43.2.7


            43.2.8


            43.2.9


            43.3.0


            43.3.1


            43.3.2


            43.3.3


            43.4.0


            43.4.1


            43.4.2


            43.4.3


            43.4.4


            43.5.0


            43.5.1


            43.5.2


            43.5.3


            43.5.4


            43.5.5

Fixed in


          43.5.6

References

Updated Jul 28, 2026 · Source: OSV.dev

Nov 28, 2025

43.1.6 patch

1 CVE

CVE-2026-54659 GHSA-2xmw-f8j8-wfxc Jul 28, 2026

Pagy I18n locale option is not validated before being used in a file path

Medium

Network Low None None

Summary

Pagy::I18n.locale= did not validate its argument before using it as a path component to load the matching dictionary file (<locale>.yml). An application that assigns untrusted input to the locale — e.g. the common pattern Pagy::I18n.locale = params[:locale] — let that input influence which file Pagy attempted to load.

Details

The setter stored the value as-is, and the loader joined it into a path and read it:

# gem/lib/pagy/modules/i18n/i18n.rb
def locale=(value)
  Thread.current[:pagy_locale] = value.to_s
end

# ...later, when translating:
path = pathnames.reverse.map { |p| p.join("#{locale}.yml") }.find(&:exist?)
dictionary = YAML.load_file(path)[locale]

Because the locale was used verbatim, a value such as an absolute path or a ../-style string redirected the lookup outside the locales directory. Pagy's subsequent structural check (dictionary['pagy']['p11n']) prevents the file's contents from being returned, so this is not a direct file read.

Fixed in 43.5.6 by constraining the locale to a BCP 47 shape before use:

LOCALE_PATTERN = /\A[a-zA-Z]{2,8}(-[a-zA-Z0-9]{1,8})*\z/

def locale=(value)
  Thread.current[:pagy_locale] = value.to_s[LOCALE_PATTERN]
end

Any non-matching value (including nil) resolves to the default locale and never reaches the file lookup.

PoC

In an application that sets Pagy::I18n.locale = params[:locale], the loader appends .yml and reads <locale>.yml, so the request param controls the target path. For example, pointing it at the app's config/database.yml:

Send a request with ?locale=../../../config/database (adjust the number of ../ to reach the app root from the gem's locales/ directory).
Pagy calls YAML.load_file on the resulting …/config/database.yml.
The outcome differs by whether that .yml exists, is readable, parses as YAML, and has Pagy's expected structure — an existing, readable config/database.yml raises a different error than a non-existent path (which silently falls back to the default locale). This yields a file-existence / readability oracle for .yml paths, and the targeted file is read into the process during the attempt.

Impact

Information disclosure (CWE-22 / CWE-200): a file-existence / readability oracle for .yml paths on the host, plus a server-side read of attacker-chosen files into the process. The file contents are not returned in the response.

Only applications that pass unsanitized end-user input into Pagy::I18n.locale= are affected. Applications that set the locale from trusted values are not affected.

Patched: pagy 43.5.6. Workaround (if you cannot upgrade): validate the locale before assigning it, e.g. Pagy::I18n.locale = params[:locale].to_s[/\A[a-zA-Z]{2,8}(-[a-zA-Z0-9]{1,8})*\z/], or restrict it to your known set of locales.

Affected versions


          43.0.0


          43.0.1


          43.0.2


          43.0.3


          43.0.4


          43.0.5


          43.0.6


          43.0.7


          43.1.0


          43.1.1


          43.1.2


          43.1.3

+ 31 more


            43.1.4


            43.1.5


            43.1.6


            43.1.7


            43.1.8


            43.2.0


            43.2.1


            43.2.10


            43.2.2


            43.2.3


            43.2.4


            43.2.5


            43.2.6


            43.2.7


            43.2.8


            43.2.9


            43.3.0


            43.3.1


            43.3.2


            43.3.3


            43.4.0


            43.4.1


            43.4.2


            43.4.3


            43.4.4


            43.5.0


            43.5.1


            43.5.2


            43.5.3


            43.5.4


            43.5.5

Fixed in


          43.5.6

References

Updated Jul 28, 2026 · Source: OSV.dev

Nov 26, 2025

43.1.5 patch

1 CVE

CVE-2026-54659 GHSA-2xmw-f8j8-wfxc Jul 28, 2026

Pagy I18n locale option is not validated before being used in a file path

Medium

Network Low None None

Summary

Pagy::I18n.locale= did not validate its argument before using it as a path component to load the matching dictionary file (<locale>.yml). An application that assigns untrusted input to the locale — e.g. the common pattern Pagy::I18n.locale = params[:locale] — let that input influence which file Pagy attempted to load.

Details

The setter stored the value as-is, and the loader joined it into a path and read it:

# gem/lib/pagy/modules/i18n/i18n.rb
def locale=(value)
  Thread.current[:pagy_locale] = value.to_s
end

# ...later, when translating:
path = pathnames.reverse.map { |p| p.join("#{locale}.yml") }.find(&:exist?)
dictionary = YAML.load_file(path)[locale]

Because the locale was used verbatim, a value such as an absolute path or a ../-style string redirected the lookup outside the locales directory. Pagy's subsequent structural check (dictionary['pagy']['p11n']) prevents the file's contents from being returned, so this is not a direct file read.

Fixed in 43.5.6 by constraining the locale to a BCP 47 shape before use:

LOCALE_PATTERN = /\A[a-zA-Z]{2,8}(-[a-zA-Z0-9]{1,8})*\z/

def locale=(value)
  Thread.current[:pagy_locale] = value.to_s[LOCALE_PATTERN]
end

Any non-matching value (including nil) resolves to the default locale and never reaches the file lookup.

PoC

In an application that sets Pagy::I18n.locale = params[:locale], the loader appends .yml and reads <locale>.yml, so the request param controls the target path. For example, pointing it at the app's config/database.yml:

Send a request with ?locale=../../../config/database (adjust the number of ../ to reach the app root from the gem's locales/ directory).
Pagy calls YAML.load_file on the resulting …/config/database.yml.
The outcome differs by whether that .yml exists, is readable, parses as YAML, and has Pagy's expected structure — an existing, readable config/database.yml raises a different error than a non-existent path (which silently falls back to the default locale). This yields a file-existence / readability oracle for .yml paths, and the targeted file is read into the process during the attempt.

Impact

Information disclosure (CWE-22 / CWE-200): a file-existence / readability oracle for .yml paths on the host, plus a server-side read of attacker-chosen files into the process. The file contents are not returned in the response.

Only applications that pass unsanitized end-user input into Pagy::I18n.locale= are affected. Applications that set the locale from trusted values are not affected.

Patched: pagy 43.5.6. Workaround (if you cannot upgrade): validate the locale before assigning it, e.g. Pagy::I18n.locale = params[:locale].to_s[/\A[a-zA-Z]{2,8}(-[a-zA-Z0-9]{1,8})*\z/], or restrict it to your known set of locales.

Affected versions


          43.0.0


          43.0.1


          43.0.2


          43.0.3


          43.0.4


          43.0.5


          43.0.6


          43.0.7


          43.1.0


          43.1.1


          43.1.2


          43.1.3

+ 31 more


            43.1.4


            43.1.5


            43.1.6


            43.1.7


            43.1.8


            43.2.0


            43.2.1


            43.2.10


            43.2.2


            43.2.3


            43.2.4


            43.2.5


            43.2.6


            43.2.7


            43.2.8


            43.2.9


            43.3.0


            43.3.1


            43.3.2


            43.3.3


            43.4.0


            43.4.1


            43.4.2


            43.4.3


            43.4.4


            43.5.0


            43.5.1


            43.5.2


            43.5.3


            43.5.4


            43.5.5

Fixed in


          43.5.6

References

Updated Jul 28, 2026 · Source: OSV.dev

Nov 26, 2025

43.1.4 patch

1 CVE

CVE-2026-54659 GHSA-2xmw-f8j8-wfxc Jul 28, 2026

Pagy I18n locale option is not validated before being used in a file path

Medium

Network Low None None

Summary

Pagy::I18n.locale= did not validate its argument before using it as a path component to load the matching dictionary file (<locale>.yml). An application that assigns untrusted input to the locale — e.g. the common pattern Pagy::I18n.locale = params[:locale] — let that input influence which file Pagy attempted to load.

Details

The setter stored the value as-is, and the loader joined it into a path and read it:

# gem/lib/pagy/modules/i18n/i18n.rb
def locale=(value)
  Thread.current[:pagy_locale] = value.to_s
end

# ...later, when translating:
path = pathnames.reverse.map { |p| p.join("#{locale}.yml") }.find(&:exist?)
dictionary = YAML.load_file(path)[locale]

Because the locale was used verbatim, a value such as an absolute path or a ../-style string redirected the lookup outside the locales directory. Pagy's subsequent structural check (dictionary['pagy']['p11n']) prevents the file's contents from being returned, so this is not a direct file read.

Fixed in 43.5.6 by constraining the locale to a BCP 47 shape before use:

LOCALE_PATTERN = /\A[a-zA-Z]{2,8}(-[a-zA-Z0-9]{1,8})*\z/

def locale=(value)
  Thread.current[:pagy_locale] = value.to_s[LOCALE_PATTERN]
end

Any non-matching value (including nil) resolves to the default locale and never reaches the file lookup.

PoC

In an application that sets Pagy::I18n.locale = params[:locale], the loader appends .yml and reads <locale>.yml, so the request param controls the target path. For example, pointing it at the app's config/database.yml:

Send a request with ?locale=../../../config/database (adjust the number of ../ to reach the app root from the gem's locales/ directory).
Pagy calls YAML.load_file on the resulting …/config/database.yml.
The outcome differs by whether that .yml exists, is readable, parses as YAML, and has Pagy's expected structure — an existing, readable config/database.yml raises a different error than a non-existent path (which silently falls back to the default locale). This yields a file-existence / readability oracle for .yml paths, and the targeted file is read into the process during the attempt.

Impact

Information disclosure (CWE-22 / CWE-200): a file-existence / readability oracle for .yml paths on the host, plus a server-side read of attacker-chosen files into the process. The file contents are not returned in the response.

Only applications that pass unsanitized end-user input into Pagy::I18n.locale= are affected. Applications that set the locale from trusted values are not affected.

Patched: pagy 43.5.6. Workaround (if you cannot upgrade): validate the locale before assigning it, e.g. Pagy::I18n.locale = params[:locale].to_s[/\A[a-zA-Z]{2,8}(-[a-zA-Z0-9]{1,8})*\z/], or restrict it to your known set of locales.

Affected versions


          43.0.0


          43.0.1


          43.0.2


          43.0.3


          43.0.4


          43.0.5


          43.0.6


          43.0.7


          43.1.0


          43.1.1


          43.1.2


          43.1.3

+ 31 more


            43.1.4


            43.1.5


            43.1.6


            43.1.7


            43.1.8


            43.2.0


            43.2.1


            43.2.10


            43.2.2


            43.2.3


            43.2.4


            43.2.5


            43.2.6


            43.2.7


            43.2.8


            43.2.9


            43.3.0


            43.3.1


            43.3.2


            43.3.3


            43.4.0


            43.4.1


            43.4.2


            43.4.3


            43.4.4


            43.5.0


            43.5.1


            43.5.2


            43.5.3


            43.5.4


            43.5.5

Fixed in


          43.5.6

References

Updated Jul 28, 2026 · Source: OSV.dev

Nov 24, 2025

43.1.3 patch

1 CVE

CVE-2026-54659 GHSA-2xmw-f8j8-wfxc Jul 28, 2026

Pagy I18n locale option is not validated before being used in a file path

Medium

Network Low None None

Summary

Pagy::I18n.locale= did not validate its argument before using it as a path component to load the matching dictionary file (<locale>.yml). An application that assigns untrusted input to the locale — e.g. the common pattern Pagy::I18n.locale = params[:locale] — let that input influence which file Pagy attempted to load.

Details

The setter stored the value as-is, and the loader joined it into a path and read it:

# gem/lib/pagy/modules/i18n/i18n.rb
def locale=(value)
  Thread.current[:pagy_locale] = value.to_s
end

# ...later, when translating:
path = pathnames.reverse.map { |p| p.join("#{locale}.yml") }.find(&:exist?)
dictionary = YAML.load_file(path)[locale]

Because the locale was used verbatim, a value such as an absolute path or a ../-style string redirected the lookup outside the locales directory. Pagy's subsequent structural check (dictionary['pagy']['p11n']) prevents the file's contents from being returned, so this is not a direct file read.

Fixed in 43.5.6 by constraining the locale to a BCP 47 shape before use:

LOCALE_PATTERN = /\A[a-zA-Z]{2,8}(-[a-zA-Z0-9]{1,8})*\z/

def locale=(value)
  Thread.current[:pagy_locale] = value.to_s[LOCALE_PATTERN]
end

Any non-matching value (including nil) resolves to the default locale and never reaches the file lookup.

PoC

In an application that sets Pagy::I18n.locale = params[:locale], the loader appends .yml and reads <locale>.yml, so the request param controls the target path. For example, pointing it at the app's config/database.yml:

Send a request with ?locale=../../../config/database (adjust the number of ../ to reach the app root from the gem's locales/ directory).
Pagy calls YAML.load_file on the resulting …/config/database.yml.
The outcome differs by whether that .yml exists, is readable, parses as YAML, and has Pagy's expected structure — an existing, readable config/database.yml raises a different error than a non-existent path (which silently falls back to the default locale). This yields a file-existence / readability oracle for .yml paths, and the targeted file is read into the process during the attempt.

Impact

Information disclosure (CWE-22 / CWE-200): a file-existence / readability oracle for .yml paths on the host, plus a server-side read of attacker-chosen files into the process. The file contents are not returned in the response.

Only applications that pass unsanitized end-user input into Pagy::I18n.locale= are affected. Applications that set the locale from trusted values are not affected.

Patched: pagy 43.5.6. Workaround (if you cannot upgrade): validate the locale before assigning it, e.g. Pagy::I18n.locale = params[:locale].to_s[/\A[a-zA-Z]{2,8}(-[a-zA-Z0-9]{1,8})*\z/], or restrict it to your known set of locales.

Affected versions


          43.0.0


          43.0.1


          43.0.2


          43.0.3


          43.0.4


          43.0.5


          43.0.6


          43.0.7


          43.1.0


          43.1.1


          43.1.2


          43.1.3

+ 31 more


            43.1.4


            43.1.5


            43.1.6


            43.1.7


            43.1.8


            43.2.0


            43.2.1


            43.2.10


            43.2.2


            43.2.3


            43.2.4


            43.2.5


            43.2.6


            43.2.7


            43.2.8


            43.2.9


            43.3.0


            43.3.1


            43.3.2


            43.3.3


            43.4.0


            43.4.1


            43.4.2


            43.4.3


            43.4.4


            43.5.0


            43.5.1


            43.5.2


            43.5.3


            43.5.4


            43.5.5

Fixed in


          43.5.6

References

Updated Jul 28, 2026 · Source: OSV.dev

Nov 23, 2025

43.1.2 patch

1 CVE

CVE-2026-54659 GHSA-2xmw-f8j8-wfxc Jul 28, 2026

Pagy I18n locale option is not validated before being used in a file path

Medium

Network Low None None

Summary

Pagy::I18n.locale= did not validate its argument before using it as a path component to load the matching dictionary file (<locale>.yml). An application that assigns untrusted input to the locale — e.g. the common pattern Pagy::I18n.locale = params[:locale] — let that input influence which file Pagy attempted to load.

Details

The setter stored the value as-is, and the loader joined it into a path and read it:

# gem/lib/pagy/modules/i18n/i18n.rb
def locale=(value)
  Thread.current[:pagy_locale] = value.to_s
end

# ...later, when translating:
path = pathnames.reverse.map { |p| p.join("#{locale}.yml") }.find(&:exist?)
dictionary = YAML.load_file(path)[locale]

Because the locale was used verbatim, a value such as an absolute path or a ../-style string redirected the lookup outside the locales directory. Pagy's subsequent structural check (dictionary['pagy']['p11n']) prevents the file's contents from being returned, so this is not a direct file read.

Fixed in 43.5.6 by constraining the locale to a BCP 47 shape before use:

LOCALE_PATTERN = /\A[a-zA-Z]{2,8}(-[a-zA-Z0-9]{1,8})*\z/

def locale=(value)
  Thread.current[:pagy_locale] = value.to_s[LOCALE_PATTERN]
end

Any non-matching value (including nil) resolves to the default locale and never reaches the file lookup.

PoC

In an application that sets Pagy::I18n.locale = params[:locale], the loader appends .yml and reads <locale>.yml, so the request param controls the target path. For example, pointing it at the app's config/database.yml:

Send a request with ?locale=../../../config/database (adjust the number of ../ to reach the app root from the gem's locales/ directory).
Pagy calls YAML.load_file on the resulting …/config/database.yml.
The outcome differs by whether that .yml exists, is readable, parses as YAML, and has Pagy's expected structure — an existing, readable config/database.yml raises a different error than a non-existent path (which silently falls back to the default locale). This yields a file-existence / readability oracle for .yml paths, and the targeted file is read into the process during the attempt.

Impact

Information disclosure (CWE-22 / CWE-200): a file-existence / readability oracle for .yml paths on the host, plus a server-side read of attacker-chosen files into the process. The file contents are not returned in the response.

Only applications that pass unsanitized end-user input into Pagy::I18n.locale= are affected. Applications that set the locale from trusted values are not affected.

Patched: pagy 43.5.6. Workaround (if you cannot upgrade): validate the locale before assigning it, e.g. Pagy::I18n.locale = params[:locale].to_s[/\A[a-zA-Z]{2,8}(-[a-zA-Z0-9]{1,8})*\z/], or restrict it to your known set of locales.

Affected versions


          43.0.0


          43.0.1


          43.0.2


          43.0.3


          43.0.4


          43.0.5


          43.0.6


          43.0.7


          43.1.0


          43.1.1


          43.1.2


          43.1.3

+ 31 more


            43.1.4


            43.1.5


            43.1.6


            43.1.7


            43.1.8


            43.2.0


            43.2.1


            43.2.10


            43.2.2


            43.2.3


            43.2.4


            43.2.5


            43.2.6


            43.2.7


            43.2.8


            43.2.9


            43.3.0


            43.3.1


            43.3.2


            43.3.3


            43.4.0


            43.4.1


            43.4.2


            43.4.3


            43.4.4


            43.5.0


            43.5.1


            43.5.2


            43.5.3


            43.5.4


            43.5.5

Fixed in


          43.5.6

References

Updated Jul 28, 2026 · Source: OSV.dev

Nov 22, 2025

43.1.1 patch

1 CVE

CVE-2026-54659 GHSA-2xmw-f8j8-wfxc Jul 28, 2026

Pagy I18n locale option is not validated before being used in a file path

Medium

Network Low None None

Summary

Pagy::I18n.locale= did not validate its argument before using it as a path component to load the matching dictionary file (<locale>.yml). An application that assigns untrusted input to the locale — e.g. the common pattern Pagy::I18n.locale = params[:locale] — let that input influence which file Pagy attempted to load.

Details

The setter stored the value as-is, and the loader joined it into a path and read it:

# gem/lib/pagy/modules/i18n/i18n.rb
def locale=(value)
  Thread.current[:pagy_locale] = value.to_s
end

# ...later, when translating:
path = pathnames.reverse.map { |p| p.join("#{locale}.yml") }.find(&:exist?)
dictionary = YAML.load_file(path)[locale]

Because the locale was used verbatim, a value such as an absolute path or a ../-style string redirected the lookup outside the locales directory. Pagy's subsequent structural check (dictionary['pagy']['p11n']) prevents the file's contents from being returned, so this is not a direct file read.

Fixed in 43.5.6 by constraining the locale to a BCP 47 shape before use:

LOCALE_PATTERN = /\A[a-zA-Z]{2,8}(-[a-zA-Z0-9]{1,8})*\z/

def locale=(value)
  Thread.current[:pagy_locale] = value.to_s[LOCALE_PATTERN]
end

Any non-matching value (including nil) resolves to the default locale and never reaches the file lookup.

PoC

In an application that sets Pagy::I18n.locale = params[:locale], the loader appends .yml and reads <locale>.yml, so the request param controls the target path. For example, pointing it at the app's config/database.yml:

Send a request with ?locale=../../../config/database (adjust the number of ../ to reach the app root from the gem's locales/ directory).
Pagy calls YAML.load_file on the resulting …/config/database.yml.
The outcome differs by whether that .yml exists, is readable, parses as YAML, and has Pagy's expected structure — an existing, readable config/database.yml raises a different error than a non-existent path (which silently falls back to the default locale). This yields a file-existence / readability oracle for .yml paths, and the targeted file is read into the process during the attempt.

Impact

Information disclosure (CWE-22 / CWE-200): a file-existence / readability oracle for .yml paths on the host, plus a server-side read of attacker-chosen files into the process. The file contents are not returned in the response.

Only applications that pass unsanitized end-user input into Pagy::I18n.locale= are affected. Applications that set the locale from trusted values are not affected.

Patched: pagy 43.5.6. Workaround (if you cannot upgrade): validate the locale before assigning it, e.g. Pagy::I18n.locale = params[:locale].to_s[/\A[a-zA-Z]{2,8}(-[a-zA-Z0-9]{1,8})*\z/], or restrict it to your known set of locales.

Affected versions


          43.0.0


          43.0.1


          43.0.2


          43.0.3


          43.0.4


          43.0.5


          43.0.6


          43.0.7


          43.1.0


          43.1.1


          43.1.2


          43.1.3

+ 31 more


            43.1.4


            43.1.5


            43.1.6


            43.1.7


            43.1.8


            43.2.0


            43.2.1


            43.2.10


            43.2.2


            43.2.3


            43.2.4


            43.2.5


            43.2.6


            43.2.7


            43.2.8


            43.2.9


            43.3.0


            43.3.1


            43.3.2


            43.3.3


            43.4.0


            43.4.1


            43.4.2


            43.4.3


            43.4.4


            43.5.0


            43.5.1


            43.5.2


            43.5.3


            43.5.4


            43.5.5

Fixed in


          43.5.6

References

Updated Jul 28, 2026 · Source: OSV.dev

Nov 21, 2025

43.1.0 minor

1 CVE

CVE-2026-54659 GHSA-2xmw-f8j8-wfxc Jul 28, 2026

Pagy I18n locale option is not validated before being used in a file path

Medium

Network Low None None

Summary

Pagy::I18n.locale= did not validate its argument before using it as a path component to load the matching dictionary file (<locale>.yml). An application that assigns untrusted input to the locale — e.g. the common pattern Pagy::I18n.locale = params[:locale] — let that input influence which file Pagy attempted to load.

Details

The setter stored the value as-is, and the loader joined it into a path and read it:

# gem/lib/pagy/modules/i18n/i18n.rb
def locale=(value)
  Thread.current[:pagy_locale] = value.to_s
end

# ...later, when translating:
path = pathnames.reverse.map { |p| p.join("#{locale}.yml") }.find(&:exist?)
dictionary = YAML.load_file(path)[locale]

Because the locale was used verbatim, a value such as an absolute path or a ../-style string redirected the lookup outside the locales directory. Pagy's subsequent structural check (dictionary['pagy']['p11n']) prevents the file's contents from being returned, so this is not a direct file read.

Fixed in 43.5.6 by constraining the locale to a BCP 47 shape before use:

LOCALE_PATTERN = /\A[a-zA-Z]{2,8}(-[a-zA-Z0-9]{1,8})*\z/

def locale=(value)
  Thread.current[:pagy_locale] = value.to_s[LOCALE_PATTERN]
end

Any non-matching value (including nil) resolves to the default locale and never reaches the file lookup.

PoC

In an application that sets Pagy::I18n.locale = params[:locale], the loader appends .yml and reads <locale>.yml, so the request param controls the target path. For example, pointing it at the app's config/database.yml:

Send a request with ?locale=../../../config/database (adjust the number of ../ to reach the app root from the gem's locales/ directory).
Pagy calls YAML.load_file on the resulting …/config/database.yml.
The outcome differs by whether that .yml exists, is readable, parses as YAML, and has Pagy's expected structure — an existing, readable config/database.yml raises a different error than a non-existent path (which silently falls back to the default locale). This yields a file-existence / readability oracle for .yml paths, and the targeted file is read into the process during the attempt.

Impact

Information disclosure (CWE-22 / CWE-200): a file-existence / readability oracle for .yml paths on the host, plus a server-side read of attacker-chosen files into the process. The file contents are not returned in the response.

Only applications that pass unsanitized end-user input into Pagy::I18n.locale= are affected. Applications that set the locale from trusted values are not affected.

Patched: pagy 43.5.6. Workaround (if you cannot upgrade): validate the locale before assigning it, e.g. Pagy::I18n.locale = params[:locale].to_s[/\A[a-zA-Z]{2,8}(-[a-zA-Z0-9]{1,8})*\z/], or restrict it to your known set of locales.

Affected versions


          43.0.0


          43.0.1


          43.0.2


          43.0.3


          43.0.4


          43.0.5


          43.0.6


          43.0.7


          43.1.0


          43.1.1


          43.1.2


          43.1.3

+ 31 more


            43.1.4


            43.1.5


            43.1.6


            43.1.7


            43.1.8


            43.2.0


            43.2.1


            43.2.10


            43.2.2


            43.2.3


            43.2.4


            43.2.5


            43.2.6


            43.2.7


            43.2.8


            43.2.9


            43.3.0


            43.3.1


            43.3.2


            43.3.3


            43.4.0


            43.4.1


            43.4.2


            43.4.3


            43.4.4


            43.5.0


            43.5.1


            43.5.2


            43.5.3


            43.5.4


            43.5.5

Fixed in


          43.5.6

References

Updated Jul 28, 2026 · Source: OSV.dev

Nov 20, 2025

43.0.7 patch

1 CVE

CVE-2026-54659 GHSA-2xmw-f8j8-wfxc Jul 28, 2026

Pagy I18n locale option is not validated before being used in a file path

Medium

Network Low None None

Summary

Pagy::I18n.locale= did not validate its argument before using it as a path component to load the matching dictionary file (<locale>.yml). An application that assigns untrusted input to the locale — e.g. the common pattern Pagy::I18n.locale = params[:locale] — let that input influence which file Pagy attempted to load.

Details

The setter stored the value as-is, and the loader joined it into a path and read it:

# gem/lib/pagy/modules/i18n/i18n.rb
def locale=(value)
  Thread.current[:pagy_locale] = value.to_s
end

# ...later, when translating:
path = pathnames.reverse.map { |p| p.join("#{locale}.yml") }.find(&:exist?)
dictionary = YAML.load_file(path)[locale]

Because the locale was used verbatim, a value such as an absolute path or a ../-style string redirected the lookup outside the locales directory. Pagy's subsequent structural check (dictionary['pagy']['p11n']) prevents the file's contents from being returned, so this is not a direct file read.

Fixed in 43.5.6 by constraining the locale to a BCP 47 shape before use:

LOCALE_PATTERN = /\A[a-zA-Z]{2,8}(-[a-zA-Z0-9]{1,8})*\z/

def locale=(value)
  Thread.current[:pagy_locale] = value.to_s[LOCALE_PATTERN]
end

Any non-matching value (including nil) resolves to the default locale and never reaches the file lookup.

PoC

In an application that sets Pagy::I18n.locale = params[:locale], the loader appends .yml and reads <locale>.yml, so the request param controls the target path. For example, pointing it at the app's config/database.yml:

Send a request with ?locale=../../../config/database (adjust the number of ../ to reach the app root from the gem's locales/ directory).
Pagy calls YAML.load_file on the resulting …/config/database.yml.
The outcome differs by whether that .yml exists, is readable, parses as YAML, and has Pagy's expected structure — an existing, readable config/database.yml raises a different error than a non-existent path (which silently falls back to the default locale). This yields a file-existence / readability oracle for .yml paths, and the targeted file is read into the process during the attempt.

Impact

Information disclosure (CWE-22 / CWE-200): a file-existence / readability oracle for .yml paths on the host, plus a server-side read of attacker-chosen files into the process. The file contents are not returned in the response.

Only applications that pass unsanitized end-user input into Pagy::I18n.locale= are affected. Applications that set the locale from trusted values are not affected.

Patched: pagy 43.5.6. Workaround (if you cannot upgrade): validate the locale before assigning it, e.g. Pagy::I18n.locale = params[:locale].to_s[/\A[a-zA-Z]{2,8}(-[a-zA-Z0-9]{1,8})*\z/], or restrict it to your known set of locales.

Affected versions


          43.0.0


          43.0.1


          43.0.2


          43.0.3


          43.0.4


          43.0.5


          43.0.6


          43.0.7


          43.1.0


          43.1.1


          43.1.2


          43.1.3

+ 31 more


            43.1.4


            43.1.5


            43.1.6


            43.1.7


            43.1.8


            43.2.0


            43.2.1


            43.2.10


            43.2.2


            43.2.3


            43.2.4


            43.2.5


            43.2.6


            43.2.7


            43.2.8


            43.2.9


            43.3.0


            43.3.1


            43.3.2


            43.3.3


            43.4.0


            43.4.1


            43.4.2


            43.4.3


            43.4.4


            43.5.0


            43.5.1


            43.5.2


            43.5.3


            43.5.4


            43.5.5

Fixed in


          43.5.6

References

Updated Jul 28, 2026 · Source: OSV.dev

Nov 18, 2025

43.0.6 patch

1 CVE

CVE-2026-54659 GHSA-2xmw-f8j8-wfxc Jul 28, 2026

Pagy I18n locale option is not validated before being used in a file path

Medium

Network Low None None

Summary

Pagy::I18n.locale= did not validate its argument before using it as a path component to load the matching dictionary file (<locale>.yml). An application that assigns untrusted input to the locale — e.g. the common pattern Pagy::I18n.locale = params[:locale] — let that input influence which file Pagy attempted to load.

Details

The setter stored the value as-is, and the loader joined it into a path and read it:

# gem/lib/pagy/modules/i18n/i18n.rb
def locale=(value)
  Thread.current[:pagy_locale] = value.to_s
end

# ...later, when translating:
path = pathnames.reverse.map { |p| p.join("#{locale}.yml") }.find(&:exist?)
dictionary = YAML.load_file(path)[locale]

Because the locale was used verbatim, a value such as an absolute path or a ../-style string redirected the lookup outside the locales directory. Pagy's subsequent structural check (dictionary['pagy']['p11n']) prevents the file's contents from being returned, so this is not a direct file read.

Fixed in 43.5.6 by constraining the locale to a BCP 47 shape before use:

LOCALE_PATTERN = /\A[a-zA-Z]{2,8}(-[a-zA-Z0-9]{1,8})*\z/

def locale=(value)
  Thread.current[:pagy_locale] = value.to_s[LOCALE_PATTERN]
end

Any non-matching value (including nil) resolves to the default locale and never reaches the file lookup.

PoC

In an application that sets Pagy::I18n.locale = params[:locale], the loader appends .yml and reads <locale>.yml, so the request param controls the target path. For example, pointing it at the app's config/database.yml:

Send a request with ?locale=../../../config/database (adjust the number of ../ to reach the app root from the gem's locales/ directory).
Pagy calls YAML.load_file on the resulting …/config/database.yml.
The outcome differs by whether that .yml exists, is readable, parses as YAML, and has Pagy's expected structure — an existing, readable config/database.yml raises a different error than a non-existent path (which silently falls back to the default locale). This yields a file-existence / readability oracle for .yml paths, and the targeted file is read into the process during the attempt.

Impact

Information disclosure (CWE-22 / CWE-200): a file-existence / readability oracle for .yml paths on the host, plus a server-side read of attacker-chosen files into the process. The file contents are not returned in the response.

Only applications that pass unsanitized end-user input into Pagy::I18n.locale= are affected. Applications that set the locale from trusted values are not affected.

Patched: pagy 43.5.6. Workaround (if you cannot upgrade): validate the locale before assigning it, e.g. Pagy::I18n.locale = params[:locale].to_s[/\A[a-zA-Z]{2,8}(-[a-zA-Z0-9]{1,8})*\z/], or restrict it to your known set of locales.

Affected versions


          43.0.0


          43.0.1


          43.0.2


          43.0.3


          43.0.4


          43.0.5


          43.0.6


          43.0.7


          43.1.0


          43.1.1


          43.1.2


          43.1.3

+ 31 more


            43.1.4


            43.1.5


            43.1.6


            43.1.7


            43.1.8


            43.2.0


            43.2.1


            43.2.10


            43.2.2


            43.2.3


            43.2.4


            43.2.5


            43.2.6


            43.2.7


            43.2.8


            43.2.9


            43.3.0


            43.3.1


            43.3.2


            43.3.3


            43.4.0


            43.4.1


            43.4.2


            43.4.3


            43.4.4


            43.5.0


            43.5.1


            43.5.2


            43.5.3


            43.5.4


            43.5.5

Fixed in


          43.5.6

References

Updated Jul 28, 2026 · Source: OSV.dev

Nov 15, 2025

43.0.5 patch

1 CVE

CVE-2026-54659 GHSA-2xmw-f8j8-wfxc Jul 28, 2026

Pagy I18n locale option is not validated before being used in a file path

Medium

Network Low None None

Summary

Pagy::I18n.locale= did not validate its argument before using it as a path component to load the matching dictionary file (<locale>.yml). An application that assigns untrusted input to the locale — e.g. the common pattern Pagy::I18n.locale = params[:locale] — let that input influence which file Pagy attempted to load.

Details

The setter stored the value as-is, and the loader joined it into a path and read it:

# gem/lib/pagy/modules/i18n/i18n.rb
def locale=(value)
  Thread.current[:pagy_locale] = value.to_s
end

# ...later, when translating:
path = pathnames.reverse.map { |p| p.join("#{locale}.yml") }.find(&:exist?)
dictionary = YAML.load_file(path)[locale]

Because the locale was used verbatim, a value such as an absolute path or a ../-style string redirected the lookup outside the locales directory. Pagy's subsequent structural check (dictionary['pagy']['p11n']) prevents the file's contents from being returned, so this is not a direct file read.

Fixed in 43.5.6 by constraining the locale to a BCP 47 shape before use:

LOCALE_PATTERN = /\A[a-zA-Z]{2,8}(-[a-zA-Z0-9]{1,8})*\z/

def locale=(value)
  Thread.current[:pagy_locale] = value.to_s[LOCALE_PATTERN]
end

Any non-matching value (including nil) resolves to the default locale and never reaches the file lookup.

PoC

In an application that sets Pagy::I18n.locale = params[:locale], the loader appends .yml and reads <locale>.yml, so the request param controls the target path. For example, pointing it at the app's config/database.yml:

Send a request with ?locale=../../../config/database (adjust the number of ../ to reach the app root from the gem's locales/ directory).
Pagy calls YAML.load_file on the resulting …/config/database.yml.
The outcome differs by whether that .yml exists, is readable, parses as YAML, and has Pagy's expected structure — an existing, readable config/database.yml raises a different error than a non-existent path (which silently falls back to the default locale). This yields a file-existence / readability oracle for .yml paths, and the targeted file is read into the process during the attempt.

Impact

Information disclosure (CWE-22 / CWE-200): a file-existence / readability oracle for .yml paths on the host, plus a server-side read of attacker-chosen files into the process. The file contents are not returned in the response.

Only applications that pass unsanitized end-user input into Pagy::I18n.locale= are affected. Applications that set the locale from trusted values are not affected.

Patched: pagy 43.5.6. Workaround (if you cannot upgrade): validate the locale before assigning it, e.g. Pagy::I18n.locale = params[:locale].to_s[/\A[a-zA-Z]{2,8}(-[a-zA-Z0-9]{1,8})*\z/], or restrict it to your known set of locales.

Affected versions


          43.0.0


          43.0.1


          43.0.2


          43.0.3


          43.0.4


          43.0.5


          43.0.6


          43.0.7


          43.1.0


          43.1.1


          43.1.2


          43.1.3

+ 31 more


            43.1.4


            43.1.5


            43.1.6


            43.1.7


            43.1.8


            43.2.0


            43.2.1


            43.2.10


            43.2.2


            43.2.3


            43.2.4


            43.2.5


            43.2.6


            43.2.7


            43.2.8


            43.2.9


            43.3.0


            43.3.1


            43.3.2


            43.3.3


            43.4.0


            43.4.1


            43.4.2


            43.4.3


            43.4.4


            43.5.0


            43.5.1


            43.5.2


            43.5.3


            43.5.4


            43.5.5

Fixed in


          43.5.6

References

Updated Jul 28, 2026 · Source: OSV.dev

Nov 14, 2025

43.0.4 patch

1 CVE

CVE-2026-54659 GHSA-2xmw-f8j8-wfxc Jul 28, 2026

Pagy I18n locale option is not validated before being used in a file path

Medium

Network Low None None

Summary

Pagy::I18n.locale= did not validate its argument before using it as a path component to load the matching dictionary file (<locale>.yml). An application that assigns untrusted input to the locale — e.g. the common pattern Pagy::I18n.locale = params[:locale] — let that input influence which file Pagy attempted to load.

Details

The setter stored the value as-is, and the loader joined it into a path and read it:

# gem/lib/pagy/modules/i18n/i18n.rb
def locale=(value)
  Thread.current[:pagy_locale] = value.to_s
end

# ...later, when translating:
path = pathnames.reverse.map { |p| p.join("#{locale}.yml") }.find(&:exist?)
dictionary = YAML.load_file(path)[locale]

Because the locale was used verbatim, a value such as an absolute path or a ../-style string redirected the lookup outside the locales directory. Pagy's subsequent structural check (dictionary['pagy']['p11n']) prevents the file's contents from being returned, so this is not a direct file read.

Fixed in 43.5.6 by constraining the locale to a BCP 47 shape before use:

LOCALE_PATTERN = /\A[a-zA-Z]{2,8}(-[a-zA-Z0-9]{1,8})*\z/

def locale=(value)
  Thread.current[:pagy_locale] = value.to_s[LOCALE_PATTERN]
end

Any non-matching value (including nil) resolves to the default locale and never reaches the file lookup.

PoC

In an application that sets Pagy::I18n.locale = params[:locale], the loader appends .yml and reads <locale>.yml, so the request param controls the target path. For example, pointing it at the app's config/database.yml:

Send a request with ?locale=../../../config/database (adjust the number of ../ to reach the app root from the gem's locales/ directory).
Pagy calls YAML.load_file on the resulting …/config/database.yml.
The outcome differs by whether that .yml exists, is readable, parses as YAML, and has Pagy's expected structure — an existing, readable config/database.yml raises a different error than a non-existent path (which silently falls back to the default locale). This yields a file-existence / readability oracle for .yml paths, and the targeted file is read into the process during the attempt.

Impact

Information disclosure (CWE-22 / CWE-200): a file-existence / readability oracle for .yml paths on the host, plus a server-side read of attacker-chosen files into the process. The file contents are not returned in the response.

Only applications that pass unsanitized end-user input into Pagy::I18n.locale= are affected. Applications that set the locale from trusted values are not affected.

Patched: pagy 43.5.6. Workaround (if you cannot upgrade): validate the locale before assigning it, e.g. Pagy::I18n.locale = params[:locale].to_s[/\A[a-zA-Z]{2,8}(-[a-zA-Z0-9]{1,8})*\z/], or restrict it to your known set of locales.

Affected versions


          43.0.0


          43.0.1


          43.0.2


          43.0.3


          43.0.4


          43.0.5


          43.0.6


          43.0.7


          43.1.0


          43.1.1


          43.1.2


          43.1.3

+ 31 more


            43.1.4


            43.1.5


            43.1.6


            43.1.7


            43.1.8


            43.2.0


            43.2.1


            43.2.10


            43.2.2


            43.2.3


            43.2.4


            43.2.5


            43.2.6


            43.2.7


            43.2.8


            43.2.9


            43.3.0


            43.3.1


            43.3.2


            43.3.3


            43.4.0


            43.4.1


            43.4.2


            43.4.3


            43.4.4


            43.5.0


            43.5.1


            43.5.2


            43.5.3


            43.5.4


            43.5.5

Fixed in


          43.5.6

References

Updated Jul 28, 2026 · Source: OSV.dev

Nov 13, 2025

43.0.3 patch

1 CVE

CVE-2026-54659 GHSA-2xmw-f8j8-wfxc Jul 28, 2026

Pagy I18n locale option is not validated before being used in a file path

Medium

Network Low None None

Summary

Pagy::I18n.locale= did not validate its argument before using it as a path component to load the matching dictionary file (<locale>.yml). An application that assigns untrusted input to the locale — e.g. the common pattern Pagy::I18n.locale = params[:locale] — let that input influence which file Pagy attempted to load.

Details

The setter stored the value as-is, and the loader joined it into a path and read it:

# gem/lib/pagy/modules/i18n/i18n.rb
def locale=(value)
  Thread.current[:pagy_locale] = value.to_s
end

# ...later, when translating:
path = pathnames.reverse.map { |p| p.join("#{locale}.yml") }.find(&:exist?)
dictionary = YAML.load_file(path)[locale]

Because the locale was used verbatim, a value such as an absolute path or a ../-style string redirected the lookup outside the locales directory. Pagy's subsequent structural check (dictionary['pagy']['p11n']) prevents the file's contents from being returned, so this is not a direct file read.

Fixed in 43.5.6 by constraining the locale to a BCP 47 shape before use:

LOCALE_PATTERN = /\A[a-zA-Z]{2,8}(-[a-zA-Z0-9]{1,8})*\z/

def locale=(value)
  Thread.current[:pagy_locale] = value.to_s[LOCALE_PATTERN]
end

Any non-matching value (including nil) resolves to the default locale and never reaches the file lookup.

PoC

In an application that sets Pagy::I18n.locale = params[:locale], the loader appends .yml and reads <locale>.yml, so the request param controls the target path. For example, pointing it at the app's config/database.yml:

Send a request with ?locale=../../../config/database (adjust the number of ../ to reach the app root from the gem's locales/ directory).
Pagy calls YAML.load_file on the resulting …/config/database.yml.
The outcome differs by whether that .yml exists, is readable, parses as YAML, and has Pagy's expected structure — an existing, readable config/database.yml raises a different error than a non-existent path (which silently falls back to the default locale). This yields a file-existence / readability oracle for .yml paths, and the targeted file is read into the process during the attempt.

Impact

Information disclosure (CWE-22 / CWE-200): a file-existence / readability oracle for .yml paths on the host, plus a server-side read of attacker-chosen files into the process. The file contents are not returned in the response.

Only applications that pass unsanitized end-user input into Pagy::I18n.locale= are affected. Applications that set the locale from trusted values are not affected.

Patched: pagy 43.5.6. Workaround (if you cannot upgrade): validate the locale before assigning it, e.g. Pagy::I18n.locale = params[:locale].to_s[/\A[a-zA-Z]{2,8}(-[a-zA-Z0-9]{1,8})*\z/], or restrict it to your known set of locales.

Affected versions


          43.0.0


          43.0.1


          43.0.2


          43.0.3


          43.0.4


          43.0.5


          43.0.6


          43.0.7


          43.1.0


          43.1.1


          43.1.2


          43.1.3

+ 31 more


            43.1.4


            43.1.5


            43.1.6


            43.1.7


            43.1.8


            43.2.0


            43.2.1


            43.2.10


            43.2.2


            43.2.3


            43.2.4


            43.2.5


            43.2.6


            43.2.7


            43.2.8


            43.2.9


            43.3.0


            43.3.1


            43.3.2


            43.3.3


            43.4.0


            43.4.1


            43.4.2


            43.4.3


            43.4.4


            43.5.0


            43.5.1


            43.5.2


            43.5.3


            43.5.4


            43.5.5

Fixed in


          43.5.6

References

Updated Jul 28, 2026 · Source: OSV.dev

Nov 12, 2025

43.0.2 patch

1 CVE

CVE-2026-54659 GHSA-2xmw-f8j8-wfxc Jul 28, 2026

Pagy I18n locale option is not validated before being used in a file path

Medium

Network Low None None

Summary

Pagy::I18n.locale= did not validate its argument before using it as a path component to load the matching dictionary file (<locale>.yml). An application that assigns untrusted input to the locale — e.g. the common pattern Pagy::I18n.locale = params[:locale] — let that input influence which file Pagy attempted to load.

Details

The setter stored the value as-is, and the loader joined it into a path and read it:

# gem/lib/pagy/modules/i18n/i18n.rb
def locale=(value)
  Thread.current[:pagy_locale] = value.to_s
end

# ...later, when translating:
path = pathnames.reverse.map { |p| p.join("#{locale}.yml") }.find(&:exist?)
dictionary = YAML.load_file(path)[locale]

Because the locale was used verbatim, a value such as an absolute path or a ../-style string redirected the lookup outside the locales directory. Pagy's subsequent structural check (dictionary['pagy']['p11n']) prevents the file's contents from being returned, so this is not a direct file read.

Fixed in 43.5.6 by constraining the locale to a BCP 47 shape before use:

LOCALE_PATTERN = /\A[a-zA-Z]{2,8}(-[a-zA-Z0-9]{1,8})*\z/

def locale=(value)
  Thread.current[:pagy_locale] = value.to_s[LOCALE_PATTERN]
end

Any non-matching value (including nil) resolves to the default locale and never reaches the file lookup.

PoC

In an application that sets Pagy::I18n.locale = params[:locale], the loader appends .yml and reads <locale>.yml, so the request param controls the target path. For example, pointing it at the app's config/database.yml:

Send a request with ?locale=../../../config/database (adjust the number of ../ to reach the app root from the gem's locales/ directory).
Pagy calls YAML.load_file on the resulting …/config/database.yml.
The outcome differs by whether that .yml exists, is readable, parses as YAML, and has Pagy's expected structure — an existing, readable config/database.yml raises a different error than a non-existent path (which silently falls back to the default locale). This yields a file-existence / readability oracle for .yml paths, and the targeted file is read into the process during the attempt.

Impact

Information disclosure (CWE-22 / CWE-200): a file-existence / readability oracle for .yml paths on the host, plus a server-side read of attacker-chosen files into the process. The file contents are not returned in the response.

Only applications that pass unsanitized end-user input into Pagy::I18n.locale= are affected. Applications that set the locale from trusted values are not affected.

Patched: pagy 43.5.6. Workaround (if you cannot upgrade): validate the locale before assigning it, e.g. Pagy::I18n.locale = params[:locale].to_s[/\A[a-zA-Z]{2,8}(-[a-zA-Z0-9]{1,8})*\z/], or restrict it to your known set of locales.

Affected versions


          43.0.0


          43.0.1


          43.0.2


          43.0.3


          43.0.4


          43.0.5


          43.0.6


          43.0.7


          43.1.0


          43.1.1


          43.1.2


          43.1.3

+ 31 more


            43.1.4


            43.1.5


            43.1.6


            43.1.7


            43.1.8


            43.2.0


            43.2.1


            43.2.10


            43.2.2


            43.2.3


            43.2.4


            43.2.5


            43.2.6


            43.2.7


            43.2.8


            43.2.9


            43.3.0


            43.3.1


            43.3.2


            43.3.3


            43.4.0


            43.4.1


            43.4.2


            43.4.3


            43.4.4


            43.5.0


            43.5.1


            43.5.2


            43.5.3


            43.5.4


            43.5.5

Fixed in


          43.5.6

References

Updated Jul 28, 2026 · Source: OSV.dev

Nov 11, 2025

43.0.1 patch

1 CVE

CVE-2026-54659 GHSA-2xmw-f8j8-wfxc Jul 28, 2026

Pagy I18n locale option is not validated before being used in a file path

Medium

Network Low None None

Summary

Pagy::I18n.locale= did not validate its argument before using it as a path component to load the matching dictionary file (<locale>.yml). An application that assigns untrusted input to the locale — e.g. the common pattern Pagy::I18n.locale = params[:locale] — let that input influence which file Pagy attempted to load.

Details

The setter stored the value as-is, and the loader joined it into a path and read it:

# gem/lib/pagy/modules/i18n/i18n.rb
def locale=(value)
  Thread.current[:pagy_locale] = value.to_s
end

# ...later, when translating:
path = pathnames.reverse.map { |p| p.join("#{locale}.yml") }.find(&:exist?)
dictionary = YAML.load_file(path)[locale]

Because the locale was used verbatim, a value such as an absolute path or a ../-style string redirected the lookup outside the locales directory. Pagy's subsequent structural check (dictionary['pagy']['p11n']) prevents the file's contents from being returned, so this is not a direct file read.

Fixed in 43.5.6 by constraining the locale to a BCP 47 shape before use:

LOCALE_PATTERN = /\A[a-zA-Z]{2,8}(-[a-zA-Z0-9]{1,8})*\z/

def locale=(value)
  Thread.current[:pagy_locale] = value.to_s[LOCALE_PATTERN]
end

Any non-matching value (including nil) resolves to the default locale and never reaches the file lookup.

PoC

In an application that sets Pagy::I18n.locale = params[:locale], the loader appends .yml and reads <locale>.yml, so the request param controls the target path. For example, pointing it at the app's config/database.yml:

Send a request with ?locale=../../../config/database (adjust the number of ../ to reach the app root from the gem's locales/ directory).
Pagy calls YAML.load_file on the resulting …/config/database.yml.
The outcome differs by whether that .yml exists, is readable, parses as YAML, and has Pagy's expected structure — an existing, readable config/database.yml raises a different error than a non-existent path (which silently falls back to the default locale). This yields a file-existence / readability oracle for .yml paths, and the targeted file is read into the process during the attempt.

Impact

Information disclosure (CWE-22 / CWE-200): a file-existence / readability oracle for .yml paths on the host, plus a server-side read of attacker-chosen files into the process. The file contents are not returned in the response.

Only applications that pass unsanitized end-user input into Pagy::I18n.locale= are affected. Applications that set the locale from trusted values are not affected.

Patched: pagy 43.5.6. Workaround (if you cannot upgrade): validate the locale before assigning it, e.g. Pagy::I18n.locale = params[:locale].to_s[/\A[a-zA-Z]{2,8}(-[a-zA-Z0-9]{1,8})*\z/], or restrict it to your known set of locales.

Affected versions


          43.0.0


          43.0.1


          43.0.2


          43.0.3


          43.0.4


          43.0.5


          43.0.6


          43.0.7


          43.1.0


          43.1.1


          43.1.2


          43.1.3

+ 31 more


            43.1.4


            43.1.5


            43.1.6


            43.1.7


            43.1.8


            43.2.0


            43.2.1


            43.2.10


            43.2.2


            43.2.3


            43.2.4


            43.2.5


            43.2.6


            43.2.7


            43.2.8


            43.2.9


            43.3.0


            43.3.1


            43.3.2


            43.3.3


            43.4.0


            43.4.1


            43.4.2


            43.4.3


            43.4.4


            43.5.0


            43.5.1


            43.5.2


            43.5.3


            43.5.4


            43.5.5

Fixed in


          43.5.6

References

Updated Jul 28, 2026 · Source: OSV.dev

Nov 11, 2025

43.0.0 major

1 CVE

CVE-2026-54659 GHSA-2xmw-f8j8-wfxc Jul 28, 2026

Pagy I18n locale option is not validated before being used in a file path

Medium

Network Low None None

Summary

Pagy::I18n.locale= did not validate its argument before using it as a path component to load the matching dictionary file (<locale>.yml). An application that assigns untrusted input to the locale — e.g. the common pattern Pagy::I18n.locale = params[:locale] — let that input influence which file Pagy attempted to load.

Details

The setter stored the value as-is, and the loader joined it into a path and read it:

# gem/lib/pagy/modules/i18n/i18n.rb
def locale=(value)
  Thread.current[:pagy_locale] = value.to_s
end

# ...later, when translating:
path = pathnames.reverse.map { |p| p.join("#{locale}.yml") }.find(&:exist?)
dictionary = YAML.load_file(path)[locale]

Because the locale was used verbatim, a value such as an absolute path or a ../-style string redirected the lookup outside the locales directory. Pagy's subsequent structural check (dictionary['pagy']['p11n']) prevents the file's contents from being returned, so this is not a direct file read.

Fixed in 43.5.6 by constraining the locale to a BCP 47 shape before use:

LOCALE_PATTERN = /\A[a-zA-Z]{2,8}(-[a-zA-Z0-9]{1,8})*\z/

def locale=(value)
  Thread.current[:pagy_locale] = value.to_s[LOCALE_PATTERN]
end

Any non-matching value (including nil) resolves to the default locale and never reaches the file lookup.

PoC

In an application that sets Pagy::I18n.locale = params[:locale], the loader appends .yml and reads <locale>.yml, so the request param controls the target path. For example, pointing it at the app's config/database.yml:

Send a request with ?locale=../../../config/database (adjust the number of ../ to reach the app root from the gem's locales/ directory).
Pagy calls YAML.load_file on the resulting …/config/database.yml.
The outcome differs by whether that .yml exists, is readable, parses as YAML, and has Pagy's expected structure — an existing, readable config/database.yml raises a different error than a non-existent path (which silently falls back to the default locale). This yields a file-existence / readability oracle for .yml paths, and the targeted file is read into the process during the attempt.

Impact

Information disclosure (CWE-22 / CWE-200): a file-existence / readability oracle for .yml paths on the host, plus a server-side read of attacker-chosen files into the process. The file contents are not returned in the response.

Only applications that pass unsanitized end-user input into Pagy::I18n.locale= are affected. Applications that set the locale from trusted values are not affected.

Patched: pagy 43.5.6. Workaround (if you cannot upgrade): validate the locale before assigning it, e.g. Pagy::I18n.locale = params[:locale].to_s[/\A[a-zA-Z]{2,8}(-[a-zA-Z0-9]{1,8})*\z/], or restrict it to your known set of locales.

Affected versions


          43.0.0


          43.0.1


          43.0.2


          43.0.3


          43.0.4


          43.0.5


          43.0.6


          43.0.7


          43.1.0


          43.1.1


          43.1.2


          43.1.3

+ 31 more


            43.1.4


            43.1.5


            43.1.6


            43.1.7


            43.1.8


            43.2.0


            43.2.1


            43.2.10


            43.2.2


            43.2.3


            43.2.4


            43.2.5


            43.2.6


            43.2.7


            43.2.8


            43.2.9


            43.3.0


            43.3.1


            43.3.2


            43.3.3


            43.4.0


            43.4.1


            43.4.2


            43.4.3


            43.4.4


            43.5.0


            43.5.1


            43.5.2


            43.5.3


            43.5.4


            43.5.5

Fixed in


          43.5.6

References

Updated Jul 28, 2026 · Source: OSV.dev

Nov 03, 2025

43.0.0.rc4 pre

Aug 20, 2025

43.0.0.rc3 pre

Aug 17, 2025

9.4.0 minor

Aug 13, 2025

Activity

Reach

Details