flawopen.com/Insecure Deserialization/Ruby YAML

Is YAML.load safe on untrusted input?

# Psych < 4: YAML.load used unsafe
# object construction by default.
YAML.load(params[:config])

# Every Psych version: explicitly unsafe.
YAML.unsafe_load(user_input)
Psych.unsafe_load(user_input)

# Marshal has no restricted safe-load API.
Marshal.load(cookie_value)

# Explicit restricted types; keep this list minimal.
require "yaml"
require "date"

data = YAML.safe_load(
  input,
  permitted_classes: [Date],
  permitted_symbols: [],
  aliases: false
)

# For ordinary external data, prefer JSON and
# validate its shape, values, and input size.
data = JSON.parse(input)

Why YAML is dangerous at all

YAML has tags that Psych can map to Ruby objects. Under an unsafe load, a tagged document can request construction of a class, with values supplied for its serialized state; impact depends on available classes and their behavior. This is the basis of deserialization gadget chains. Use safe loading for untrusted YAML, and validate the resulting data separately. The same broad risk applies to Python pickle, PHP unserialize, and Ruby Marshal.load.

Rails and other applications may load many dependencies, increasing the set of classes and behaviors available to an unsafe deserialization chain. This is a deployment-specific condition, not a property of every Rails application or every YAML document.

Why the version change caused confusion

Psych 4 changed YAML.load to use safe loading by default and introduced unsafe_load for the earlier object-construction behavior. Ruby 3.1 bundled Psych 4, but applications can select a different Psych gem version; audit the resolved dependency and runtime, not only the Ruby version. Because safe loading can reject application-specific classes or aliases, teams should migrate with a minimal explicit allowlist instead of switching to unsafe_load.

If an upgrade leads to unsafe_load, treat that call as a security finding whenever input can be influenced outside the trusted deployment boundary. Prefer safe_load with the smallest required permitted_classes list; do not broaden it merely to silence compatibility errors.

FAQ

A separate Ruby risk: Marshal.load

Separate from YAML, Ruby documents that Marshal.load can rebuild almost any class loaded in the process and may lead to remote code execution when the data is untrusted. Keep Marshal data inside a trusted boundary; never unmarshal user-supplied or attacker-influenced bytes.

References

• Ruby documentation — Psych (YAML)
• Psych 4.0 — Ruby 3.1 API documentation
• Ruby documentation — Marshal security considerations
• CVE-2024-35221 — YAML alias denial of service in RubyGems metadata
• CWE-502 — Deserialization of Untrusted Data
• Is Python's pickle safe for untrusted data?
• Is PHP's unserialize() safe on user input?
• Ruby documentation — Marshal.load security warning