From 0cdd4c185db2b3ca4312f995e2eb56648eba0221 Mon Sep 17 00:00:00 2001 From: Alexandre Daubois Date: Mon, 7 Sep 2026 14:36:22 +0200 Subject: [PATCH] Add more rejected examples in SECURITY.md --- SECURITY.md | 25 +++++++++++++++++++++++++ 1 file changed, 25 insertions(+) diff --git a/SECURITY.md b/SECURITY.md index 24801b3b4e43..8f203a443896 100644 --- a/SECURITY.md +++ b/SECURITY.md @@ -36,6 +36,31 @@ are not limited to): - Malicious `unserialize()` inputs. +- Memory exhaustion from a size the input declares, where `memory_limit` + refuses the allocation and only the current request dies. Reaching a limit + that works as designed is a robustness issue at best. + +# Writing a Report We Can Act On + +We spend most of a triage rebuilding what a report left out, so cover these +points: + +- Reproduce it on a supported branch, through a normal PHP entry point. A crash + is enough, you do not need to write a working exploit. A crash reached only + from a custom fuzzing harness, or by calling an internal C function, leaves + reachability open. + +- Tell us if you ran under a sanitizer, a debug build or `USE_ZEND_ALLOC=0`. + The last one turns every `emalloc()` into a bare `malloc()` and drops the + `memory_limit` check, so we read the trace differently. + +- Skip the theatrics. Drop the impact essay, send a short reproducer with the + few lines that matter, and make each point once. + +- Separate what you observed from what you inferred. A rough CVSS is fine, we + re-derive severity anyway, but a heap corruption that turns out to be a crash + costs us a full analysis. + # Vulnerability Policy Our full policy is described at