CVE-2026-41493

What it actually does

YARD versions prior to 0.9.42 can allow path traversal when the `yard server` component is used to serve documentation over HTTP. A remote, unauthenticated attacker can craft HTTP requests containing traversal sequences or encoded path components that escape the intended documentation directory and cause the YARD server process to read arbitrary files accessible to that process. The primary impact is confidentiality loss; the vulnerability does not inherently provide code execution, file modification, or service disruption, but exposed files may contain credentials, source code, configuration, tokens, or other sensitive data that enable follow-on compromise.

Why it matters to the business

If `yard server` is reachable over a network, attackers may be able to retrieve sensitive files from the host running it, potentially exposing application secrets, internal source material, configuration data, or credentials. Although it is not currently listed in CISA KEV and the EPSS score is low, the vulnerability is remotely exploitable without authentication and has been public for 94 days, so internet-exposed or shared development documentation servers should be treated as higher priority. Organizations using YARD only as an offline documentation generator, without running `yard server`, have materially lower exposure.

How an attack unfolds

An attacker first identifies a reachable YARD documentation server, commonly by probing HTTP services for YARD-generated documentation pages or responses associated with `yard server`. The attacker then sends crafted HTTP requests that include directory traversal payloads such as dot-dot-slash sequences, URL-encoded traversal sequences, or equivalent path normalization bypasses. On vulnerable versions prior to 0.9.42, under certain request-handling conditions, the server may fail to properly constrain the requested path to the documentation root. If successful, the server returns the contents of files elsewhere on the host that are readable by the YARD process. The attacker typically starts with harmless probes, then attempts to retrieve high-value files such as operating system account files, environment files, application configuration, SSH material, dependency credentials, or source repositories. Any recovered secrets can then be used for lateral movement, source-code theft, package publishing abuse, or access to connected services.

How to fix it

Upgrade YARD to version 0.9.42 or later wherever `yard server` is installed or used. If YARD is installed through RubyGems, update the `yard` gem and refresh lockfiles so deployed environments resolve to the patched version. If an immediate upgrade is not possible, stop using `yard server` on untrusted networks, bind it only to localhost, place it behind authenticated access controls, and restrict network access with firewall rules or reverse-proxy allowlists. Run the service as a low-privilege user with minimal filesystem read access, avoid placing secrets on hosts that serve documentation, and ensure environment files, keys, and application configuration are not readable by the YARD process. Treat public or shared development documentation servers as priority remediation targets.

How to confirm the fix worked

Confirm the installed YARD version is 0.9.42 or later using package inventory, `bundle list`, `bundle exec yard --version`, `gem list yard`, or software composition analysis tooling. Verify that no running `yard server` process is using a vulnerable gem path. Check network exposure by confirming the service is not reachable from untrusted networks unless protected by authentication and access controls. As a safe validation step, send benign traversal probes in a controlled test environment and confirm requests for files outside the documentation root are rejected, normalized safely, or return only expected errors. Review dependency lockfiles and container images to ensure older YARD versions are not retained in build artifacts or runtime images.

Typical attack path

1. Discover an exposed HTTP service running YARD documentation or `yard server`.
2. Fingerprint the service using page titles, static asset paths, response headers, or YARD documentation structure.
3. Send traversal test requests containing `../` or encoded equivalents to determine whether paths escape the documentation root.
4. Attempt to read known local files that confirm vulnerability, such as OS account files or application configuration files.
5. Harvest sensitive readable files, including environment variables, credentials, source code, SSH keys, tokens, or CI/CD configuration.
6. Use any exposed credentials or secrets for follow-on access to repositories, package registries, cloud services, databases, or internal systems.

How to detect it

Review HTTP access logs from hosts or proxies serving YARD documentation for traversal payloads, especially requests containing `../`, encoded dot-dot-slash sequences, double-encoded traversal strings, path normalization bypasses, or attempts to access well-known sensitive files. Prioritize logs for internet-facing documentation servers and any service started with `yard server`. Useful sources include web server access logs, reverse proxy logs, load balancer logs, container stdout/stderr, endpoint process telemetry, shell history, package inventory, and file access auditing where available. Investigate successful HTTP 200 responses or unusually large responses to traversal-looking requests. Look for requests targeting files such as `/etc/passwd`, `/etc/shadow`, `.env`, SSH keys, Ruby configuration files, Bundler credentials, Git metadata, or cloud credential files. If exploitation is suspected, determine which files could have been read by the YARD process user and rotate credentials that may have been exposed. Also review process telemetry for unexpected public binding of `yard server`, such as listening on `0.0.0.0` or a non-local interface.

• ../
• ..%2f
• %2e%2e%2f
• %2e%2e/
• ..%252f
• %252e%252e%252f
• ..\\
• ..%5c
• %2e%2e%5c
• /etc/passwd
• /etc/shadow
• /.env
• /proc/self/environ
• /root/.ssh/id_rsa
• /.ssh/id_rsa
• /home/
• /var/www/
• /.git/config
• /config/master.key
• /config/database.yml
• /Gemfile.lock
• /bundle/config
• /.bundle/config
• /root/.aws/credentials
• /.aws/credentials
• yard server
• yard server --reload
• yard server --gems
• yard server --adapter

What your security team should do

• Inventory all systems, containers, development hosts, and CI environments where the Ruby `yard` gem is installed, with special focus on hosts running `yard server`.
• Upgrade YARD to 0.9.42 or later and redeploy any documentation-serving containers or images built with earlier versions.
• Immediately restrict or disable externally reachable `yard server` instances until patched.
• Search HTTP access logs for traversal attempts against documentation endpoints, including raw and URL-encoded dot-dot-slash patterns.
• If suspicious file-read attempts are found, investigate whether sensitive files were returned and rotate any potentially exposed secrets, tokens, keys, and credentials.
• Run YARD services as non-privileged users and reduce filesystem permissions so documentation servers cannot read application secrets or host-level sensitive files.
• Add SIEM detections for traversal payloads targeting YARD documentation routes and generic documentation server endpoints.
• Confirm dependency lockfiles and SBOMs no longer reference YARD versions earlier than 0.9.42.