# GHSA-pcc4-rvhr-2pr8: The Fortran extractor's C-preprocessor step (`graphify/extractors/fortran.py`, `_cpp_preprocess`) applies an incomplete `#include` hardening.

> Attackers can read arbitrary host files by providing a malicious Fortran repository, as the tool's preprocessor hardening fails to block absolute paths or traversals.

- **Severity:** Not scored
- **Exploited in the wild:** Not known
- **Login needed:** Not needed
- **Attackable:** Local or same network only
- **Victim action needed:** A user has to click or open something
- **Fix available:** Yes
- **Published:** 19 Oct 2026

## What is GHSA-pcc4-rvhr-2pr8?

GHSA-pcc4-rvhr-2pr8 is a path traversal vulnerability in graphifyy, published on 19 Oct 2026. It can only be exploited from the same machine or local network, and only if a user opens a file or follows a link.

### Official description

## Summary

The Fortran extractor's C-preprocessor step (`graphify/extractors/fortran.py`, `_cpp_preprocess`) applies an incomplete `#include` hardening. The `-nostdinc -I /dev/null` flags it relies on (comment "Security (F-007)") do **not** stop a capital-`F` Fortran source file from including **absolute paths** (`#include "/etc/passwd"`) or from **path-traversing out of the corpus** (`#include "../../../../home/victim/.ssh/id_rsa"`). `cpp` always searches the directory of the file being preprocessed for quoted includes and always honours absolute include paths, regardless of `-nostdinc`/`-I`. As a result, indexing an untrusted repository that contains a `.F`/`.F90`/`.F95`/`.F03`/`.F08` file reads arbitrary local files off the host and inlines their contents into the knowledge graph, which is then shipped to the LLM/agent and written to the on-disk, shareable output (`graph.json`, `GRAPH_REPORT.md`, the Obsidian wiki, HTML/SVG exports).

This is the exact "corpus-side file-exfiltration vector" the F-007 comment says it is defending against; the mitigation is bypassable.

## Severity

High. Arbitrary local-file read on the host, triggered by graphify's core action (indexing an untrusted folder — "turn any folder of code ... into a queryable knowledge graph"), defeating a documented security control. It runs on the default, offline, no-API-key AST path (`graphify update .` / `graphify extract`) — no credentials, network, or LLM call required. CWE-73 (external control of file name/path) / CWE-22 (path traversal) / CWE-200 (information exposure).

## Where

`graphify/extractors/fortran.py`, `_cpp_preprocess()`:

    result = subprocess.run(
        ["cpp", "-w", "-P", "-nostdinc", "-I", "/dev/null", str(path.resolve())],
        capture_output=True, timeout=30,
    )

Reached from `extract_fortran()` (same file) for any suffix in `_FORTRAN_CPP_EXTS = {".F", ".F90", ".F95", ".F03", ".F08"}`, which are collected by default (`detect.CODE_EXTENSIONS`) and dispatched by `extract._DISPATCH`.

## Why the mitigation does not work

`-nostdinc` only removes the standard *system* include directories, and `-I /dev/null` only sets the *additional* search path. Neither affects:

1. Absolute includes — `#include "/etc/passwd"` is opened directly by cpp.
2. Quoted includes relative to the current file — cpp always searches the directory containing the file being preprocessed for `#include "..."`, so `#include "../../../../etc/shadow"` traverses out of the corpus.

## Proof of concept (verified)

Reproduced against the shipped code with the exact command `_cpp_preprocess` builds (`cpp -w -P -nostdinc -I /dev/null <file>`), and against `extract_fortran()` directly.

Secret on disk (`/tmp/secret.txt`): `TOP_SECRET_...`

(a) Absolute include — `evil_abs.F90`:

    program evil
    #include "/absolute/path/to/secret.txt"
    end program evil

(b) Relative traversal — `evil_rel.F90`:

    program evil
    #include "../secret.txt"
    end program evil

Both produce preprocessed output containing the full secret file contents (`"SECRET IN OUTPUT: True"` for both).

Surfacing into the graph — `leak.F90` places the include in an identifier position via a free-form continuation so the leaked value becomes a node/edge:

    module m
    contains
    subroutine s
    use &
    #include "/path/to/token.secret"
    end subroutine s
    end module m

`extract_fortran()` on this file emits a node whose label is the entire single-line contents of `token.secret` and an `imports` edge to it. That node is written to `graph.json` / `GRAPH_REPORT.md` / the wiki and returned by the MCP `query_graph` / `get_node` / `get_neighbors` tools — i.e. exfiltrated into the agent's context and into persisted, shareable artifacts.

Fidelity note: Fortran is case-insensitive, so captured identifiers are lower-cased. Case-insensitive secrets (file paths, hostnames, usernames, hex tokens, connection-string fragments, and the mere existence/partial content of a readable file) leak cleanly; high-entropy case-sensitive blobs (base64/JWT) are partially corrupted by the lower-casing but still confirm readability and structure. Single-token-per-line secret files (API-key files, single-line credential/token files) leak that token in full (lower-cased). Requires `cpp`/gcc on PATH (near-ubiquitous on the dev/CI hosts graphify targets); it cleanly falls back to raw bytes when absent.

## Suggested fix

Mirror the containment approach already used elsewhere in the codebase (`_project_xml_is_safe`, `security.validate_graph_path`): before invoking cpp, scan the source for `#include` directives and **refuse or neutralise any include whose target is absolute or resolves outside the corpus/repo root**. Concretely, in `_cpp_preprocess`:

- Parse `#include "..."` / `#include <...>` directives.
- Resolve each target against the file's directory; if it is absolute, or its `.resolve()` escapes the scan root, strip that line (or fall back to `path.read_bytes()` with no preprocessing).
- Only allow includes that resolve to a path inside the corpus root.

A blunter but safe alternative is to strip all `#include` lines before preprocessing (macros still expand; cross-file includes lose fidelity but no host files can be read). Running cpp inside a filesystem sandbox (bwrap/unshare with only the corpus mounted) would also close it but is heavier.

## Detected by

Aeon vuln-scanner. Semgrep flagged the Fortran subprocess path; manual review of the F-007 mitigation plus an empirical `cpp` repro confirmed the bypass.

## Which versions are affected by GHSA-pcc4-rvhr-2pr8?

2 open source packages ship an affected version, including graphifyy.


| Package | Ecosystem | Affected | Fixed in |
| --- | --- | --- | --- |
| `graphifyy` | PyPI | From 0.7.2 | 0.9.70 |
| `graphifyy` | PyPI | From 0.7.2 | 0.9.70 |

## How do I fix GHSA-pcc4-rvhr-2pr8?

Upgrade graphifyy to 0.9.70 or later.

## Is GHSA-pcc4-rvhr-2pr8 being exploited?

There is no known exploitation of GHSA-pcc4-rvhr-2pr8 in the wild and no public exploit code.

## Fix prompt for AI coding agents

```text
Check this codebase for GHSA-pcc4-rvhr-2pr8 and fix it if it is affected.

What it is: GHSA-pcc4-rvhr-2pr8 is a path traversal vulnerability in graphifyy, published on 19 Oct 2026. It can only be exploited from the same machine or local network, and only if a user opens a file or follows a link.
Exploitation: There is no known exploitation of GHSA-pcc4-rvhr-2pr8 in the wild and no public exploit code.

Affected packages and fixed versions:
- graphifyy (PyPI): affected from 0.7.2; fixed in 0.9.70
- graphifyy (PyPI): affected from 0.7.2; fixed in 0.9.70

Task:
1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.
2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.
3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.
4. Run the tests and summarise what changed and why.
5. If nothing in the project is affected, say so and change nothing.

Reference: https://insights.sbomify.com/GHSA-pcc4-rvhr-2pr8/ (Markdown: https://insights.sbomify.com/GHSA-pcc4-rvhr-2pr8/index.md)
```

## Sources

- OSV: https://osv.dev/vulnerability/GHSA-pcc4-rvhr-2pr8

---
From sbomify Insights: https://insights.sbomify.com/GHSA-pcc4-rvhr-2pr8/
Summaries are generated and may contain mistakes; the official description above is the record.