xFasterTransformer

Skip to content What this pays sorona.xyz pays 1.25× the program's reward, up to +$1,000 per finding, plus a complexity bonus of up to $1,000 for especially complex or well-chained bugs. Finding │ Program pays │ Through sorona.xyz Critical, CVSS 9.0-10.0 (Intel Software tier; the $100,000 headline is the Hardware tier) │ Up to $10,000 │ Up to $11,000 High and Medium, CVSS 4.0-8.9 (Intel publishes the Software tier as a whole, not a per-band figure) │ $500 - $10,000 │ $625 - $11,000 Low, CVSS 0.1-3.9 │ $500 │ $625 Submit a vulnerability CVE history 0 Last 12 months 0 Lifetime Memory safety 45 % Parsing/validation 25 % Code execution 20 % Denial of service 5 % Latest advisories Loading the feed Overview xFasterTransformer is Intel's CPU-only LLM serving engine for Xeon, used where Xeon inference replaces GPUs: mostly in Chinese cloud and enterprise deployments and in Intel's own AI reference architectures. Its footprint is narrower than the rest of Intel's AI stack, but hand-written AMX and AVX-512 kernel code parsing GGUF checkpoints is a high-quality memory-safety surface at any deployment scale, and 45% of the expected bug classes here are memory safety alone. The project is quiet: the last release was v2.1.2 in June 2025 and the last push September 2025, with no end-of-life notice, so a report has to argue that the version tested is still a supported one. Intel pays for it on Intigriti under the Software tier, up to $10,000 for a critical finding with a $500 floor, and sorona.xyz adds 1.25× on top of whatever Intel awards, up to $1,000 more, plus a complexity bonus of up to $1,000. In scope Intel accepts security issues in open-source projects it solely maintains. This repository sits in the intel organisation and its SECURITY.md points reporters at Intel's vulnerability-handling guidelines, so the whole of xFasterTransformer is the target. Software is Tier 3 at $500 to $10,000. The C++ inference engine for Xeon, including the hand-written AMX and AVX-512 kernels where bounds reasoning is done by hand rather than by a compiler Model conversion and loading: the GGUF reader, the Hugging Face checkpoint converters and the quantized weight formats the engine supports The distributed multi-rank serving path over oneCCL and MPI, where ranks exchange tensors and control data The Python API and the REST and serving wrappers that expose the engine to callers Tokenizer and prompt handling and the KV-cache management behind a generation request The build, packaging and container images the project publishes Out of scope Upstream oneCCL and oneDNN bugs that cannot be root-caused to this codebase Performance regressions, which are not security defects however severe Issues in third-party model weights rather than in the code that reads them Reports against unsupported or unbuilt configurations, including build combinations the project does not ship Pre-release builds, and end-of-life or end-of-support versions. Intel requires a currently supported release, and with the last one dating from June 2025 this is the first gate a report here has to clear Anything in Intel's *.intel.com web infrastructure, which has its own reporting address Intel's live out-of-scope table on Intigriti lists Intel-maintained open-source projects as out of scope and sends reporters to the project maintainer, which contradicts the scope section admitting projects Intel solely maintains. Confirm eligibility with Intel before committing time. Most-valued findings Heap or stack corruption in the AMX/AVX-512 kernels reachable from a crafted GGUF checkpoint or an oversized prompt: the highest-value class here and nearly half the expected bug distribution Checkpoint-conversion parsing bugs where a malformed header or tensor descriptor produces an out-of-bounds write Memory-safety or trust failures in the oneCCL multi-rank path, where one rank can corrupt another's state Remote code execution through the REST or Python serving wrapper on a Xeon inference node Prompt or tokenizer handling that overflows a fixed buffer in the C++ engine Program rules Submit through sorona.xyz first. We validate, coordinate with the program's security team, and add the payout uplift on top of whatever it awards. Demonstrate the finding "against a currently supported (often the most recent) and publicly available version" — with the last release dating from mid-2025, establish that the build you tested still counts before anything else Send the report to Intel first and discuss it with nobody Intel has not authorised, video proof-of-concept included The finding must be original, unreported and not already public; end-of-life and end-of-support products pay nothing One CVE equals one bounty, so a single kernel or parser defect reached from several serving paths is paid once You need an Intigriti account, must be 18 or over, must have your employer's approval where it is required, and must clear sanctions screening before Intel can pay Disclosure Coordinated by Intel PSIRT through the Intel Security Center, which is where the repository's SECURITY.md sends reporters. Intel sets the timing and its non-disclosure clause runs until Intel gives written consent; given how quiet the project is, expect the fix to take a full release cycle, and sorona.xyz holds the finding until Intel has published. Safe harbor Sorona will not pursue legal action against you for good-faith research submitted to us in line with this policy. We cannot speak for the upstream project, its vendor, or any third party, and we do not grant authorization on their behalf. You are responsible for understanding and following the laws that apply to you, wherever you are, and for staying within any scope the project has defined. Submit a vulnerability