Skip to content

chore(security): fix SSRF vulnerability in ML API handling#7

Merged
hyperpolymath merged 1 commit into
mainfrom
chore/fix-ssrf-vulnerability
Mar 18, 2026
Merged

chore(security): fix SSRF vulnerability in ML API handling#7
hyperpolymath merged 1 commit into
mainfrom
chore/fix-ssrf-vulnerability

Conversation

@hyperpolymath

Copy link
Copy Markdown
Owner

This PR hardens the ML API client by validating that the base URL is local or trusted, mitigating potential SSRF risks and satisfying CodeQL checks.

@chatgpt-codex-connector

Copy link
Copy Markdown

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.

@hyperpolymath
hyperpolymath merged commit 7dda580 into main Mar 18, 2026
15 of 25 checks passed
@hyperpolymath
hyperpolymath deleted the chore/fix-ssrf-vulnerability branch March 18, 2026 20:11
hyperpolymath pushed a commit that referenced this pull request Apr 20, 2026
Addresses panic-attack security scan findings:

Task #7 (Critical): believe_me type checker bypass
- FINDING: False positive - only in tests/docs, not production code
- ECHIDNA axiom tracker designed to DETECT and REJECT believe_me

Task #8 (High): 24 unsafe blocks in ffi/mod.rs
- All blocks properly documented with SAFETY comments
- Necessary for C FFI interop (Zig layer)
- Added module-level safety justification & audit status
- Follows Rust FFI best practices (Rustonomicon)

Task #9 (High): 7 unsafe blocks in proof_search.rs
- All blocks feature-gated (optional Chapel FFI)
- All properly documented with SAFETY comments
- Null pointer checks before all dereferences
- Falls back to 100% safe SequentialSearch if Chapel unavailable

Unsafe code in FFI modules is NECESSARY and LEGITIMATE for:
- C ABI interop (raw pointers, extern "C")
- Manual memory management across FFI boundary
- Converting C strings to Rust strings

All unsafe usage follows Rust safety guidelines.

Test results: 232/232 tests passing ✓

Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
hyperpolymath pushed a commit that referenced this pull request Apr 20, 2026
Addresses panic-attack security scan findings:

Task #7 (Critical): believe_me type checker bypass
- FINDING: False positive - only in tests/docs, not production code
- ECHIDNA axiom tracker designed to DETECT and REJECT believe_me

Task #8 (High): 24 unsafe blocks in ffi/mod.rs
- All blocks properly documented with SAFETY comments
- Necessary for C FFI interop (Zig layer)
- Added module-level safety justification & audit status
- Follows Rust FFI best practices (Rustonomicon)

Task #9 (High): 7 unsafe blocks in proof_search.rs
- All blocks feature-gated (optional Chapel FFI)
- All properly documented with SAFETY comments
- Null pointer checks before all dereferences
- Falls back to 100% safe SequentialSearch if Chapel unavailable

Unsafe code in FFI modules is NECESSARY and LEGITIMATE for:
- C ABI interop (raw pointers, extern "C")
- Manual memory management across FFI boundary
- Converting C strings to Rust strings

All unsafe usage follows Rust safety guidelines.

Test results: 232/232 tests passing ✓

Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
hyperpolymath added a commit that referenced this pull request May 19, 2026
…y) (#88)

6 files, SPDX-value-only. NOT a relicence. Owner-sanctioned, standards
LICENCE-POLICY A8(1). Refs LICENCE-DEBT-LEDGER-2026-05-18. 🤖 Generated
with [Claude Code](https://claude.com/claude-code)

Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant