Skip to content

Security: Swately/phyriad

Security

SECURITY.md

Security policy

Reporting a vulnerability

Do not open a public GitHub issue for security vulnerabilities. Public issues are visible to attackers before they're fixed.

Instead, use one of these private channels:

  1. GitHub Security Advisories (preferred)
    • Go to the repo's Security tab → "Report a vulnerability"
    • This creates a private advisory only maintainers can see
  2. Email the maintainer at swatelite2506@gmail.com
    • Subject prefix: [phyriad-security]
    • PGP key: not currently published; plain email is acceptable

When reporting, please include:

  • Affected version (git rev-parse HEAD or release tag)
  • Affected component (pillar name, e.g., framework/pool)
  • Threat model assumed (e.g., "untrusted task fn from network", "shared-memory IPC with a malicious peer")
  • Reproduction steps or PoC if you have one
  • Impact assessment (information disclosure, RCE, DoS, etc.)
  • Suggested fix (optional but appreciated)

What counts as a security issue

Phyriad is a library, not a service. Most CVEs in libraries fall into a few categories — Phyriad's interpretation:

Class Severity In scope?
Memory safety in framework code (UAF, OOB, double-free) 🔴 Critical ✅ Yes
Data races / lock-free correctness bugs that lead to memory safety 🔴 Critical ✅ Yes
Information disclosure across security boundaries (e.g., uninit memory in IPC payload) 🟠 High ✅ Yes
phyriad::ipc::ShmRegion deserialisation bugs (the seqlock contract) 🟠 High ✅ Yes
Schema-hash collisions exploitable for cross-version masquerade 🟠 High ✅ Yes
Plugin loader path traversal (phyriad::plugin::PluginLoader) 🟠 High ✅ Yes
Denial of service via bench / fuzz inputs to framework 🟡 Medium ✅ Yes
Build system issues (CMake injection in user-controlled paths) 🟡 Medium ✅ Yes
Performance regression > 10% 🟢 Functional bug, not security ❌ Use a regular issue
Application-level bugs in Ayama (the showcase app) 🟡 Medium ✅ Yes (separate component)
Build issues unrelated to security n/a ❌ Use a regular issue

Untrusted task functions are NOT a Phyriad-level threat. If your application accepts arbitrary void(*)(void*) noexcept from the network, that's an application-level decision and your responsibility. Phyriad provides a thread pool, not a sandbox.

Disclosure timeline

We aim for coordinated disclosure:

Day Action
0 You report the issue privately
≤ 3 Maintainer acknowledges receipt
≤ 14 Maintainer assesses severity, opens private advisory
≤ 30 Maintainer proposes a fix (longer for complex issues)
Fix ready Coordinate disclosure date with reporter
Public release CVE / GHSA published; CHANGELOG entry; reporter credited (with consent)

For critical issues (active exploitation, no workaround), we publish a hotfix release as soon as the fix is ready, then disclose.

For lower severity issues, we batch into the next regular release.

Supported versions

Version Status Security fixes?
Pre-1.0 (current) Active development ✅ Best effort
1.0.x (when released) Stable ✅ Yes
< 1.0 after 1.0 ships EOL ❌ Upgrade to 1.0
Each major version after release Supported for 12 months minimum past next major ✅ Yes

Specifically: when 2.0 releases, the latest 1.x continues to receive security fixes for 12 months. After that, users should upgrade.

Known un-trusted boundaries

Phyriad has several APIs that cross trust boundaries. Bugs in these are higher-priority for security review:

phyriad::ipc::ShmRegion<Header, Payload> — shared memory IPC

  • Trust assumption: the SHM region peer is trusted. A malicious peer CAN exploit a torn-read or schema-mismatch bug.
  • Hardening: schema-hash check at open + seqlock protocol + size validation.
  • Known limitation: if the peer process modifies the header magic without bumping the seq counter, readers may observe inconsistent state. This is documented in ShmRegion.hpp.

phyriad::plugin::PluginLoader::load_all(paths)

  • Trust assumption: plugin .so/.dll paths come from a trusted source (config file, signed by the application).
  • Hardening: no symbol resolution from untrusted strings; relies on the OS dynamic linker.
  • Known limitation: a malicious plugin with valid signature can do anything within the process. Not Phyriad's responsibility to sandbox.

phyriad::pool::PoolRuntime::submit(Task)

  • Trust assumption: the task fn pointer is application-controlled.
  • Hardening: Phyriad does NOT validate fn pointer; the application must ensure fn is callable + noexcept + non-null.
  • Out of scope: defending against malicious task fns. Use OS-level sandboxing (seccomp, restricted token, etc.) if your application takes task fns from untrusted sources.

framework/schema/SchemaHash.hpp — wire compatibility

  • Trust assumption: peers agree on the schema-hash of wire types.
  • Hardening: SHA-128 hash of the canonical type signature; collision resistance is the hash's job.
  • Known limitation: an intentional collision crafted by an attacker with control over both peers could mismatch types. Mitigation: pin schema hashes in code, validate on connect.

Sanitizer + hardening status

Phyriad's CI runs:

  • ASan + UBSan on every PR (clang 18 + libc++)
  • TSan on every PR (clang 18 + libc++)
  • Weekly full sanitizer sweep on main
  • Linux-only currently — Windows sanitizer CI is on the P3 follow-up list

Pre-release we run all of the above plus manual fuzzing on:

  • Schema parsing
  • SHM region open/read

These are not exhaustive — please report sanitizer findings even if you saw them in your local build.

Hall of fame

We thank security researchers who responsibly disclose. With your permission, contributors get credit in:

  • CHANGELOG.md entry for the version that fixes the issue
  • This file's hall of fame (below)
  • The GitHub Security Advisory

(No reports yet — Phyriad is pre-1.0.)

See also

There aren't any published security advisories