Root command and argument injection
P-01, P-06, P-07, P-25 and P-41 remove unsafe shell boundaries, validate privileged arguments and constrain identity transitions.
Verified CSF/LFD hardening
How DCSF hardens CSF/LFD against real exploit classes
DH20.29 retains the 51-item security register and bounded WebGuard. Verified cPanel EA-Nginx separates nginx client attribution from Apache backend overload signals; signed-package diagnostics preserve the trusted library boundary. Optional AI System Scan remains advisory and does not replace a security audit.
DCSF
Current release and security status
DH20.29 / 15.10.32. Published: 2026-10-08T13:33:03Z. Documentation reviewed: 2026-10-08.
The 51 P-01–P-51 identifiers describe internal remediations, not 51 assigned CVEs. Static Messenger notices are supported; legacy reCAPTCHA self-unblock is disabled.
| CVE | Package status | Rationale |
|---|---|---|
| CVE-2026-65638 | not_affected | The released Messenger removes the legacy reCAPTCHA verification and unblock command path. The former PHP challenge endpoint returns HTTP 403. The upstream request-URL shell injection path is absent. |
| CVE-2026-67402 | not_affected | The packaged Apache HTTP and HTTPS templates do not map /usr/bin through ScriptAlias. They serve static GET/HEAD content, disable executable handlers and .htaccess overrides, and deny script extensions. |
Method: signature and SHA-256 verification, then static source and configuration inspection against the advisory prerequisites. This is not a new live production exploit test. Evidence and file hashes.
This assessment applies only to the authentic reviewed package and its managed templates. It does not assess every installation or guarantee the absence of every vulnerability. Earlier releases are not assigned a status without separate verification.
Changelog JSON | Security JSON | OpenVEX | llms.txt | llms-full.txt
DCSF
Nine exploit classes addressed in DH20.29
Each class is linked to public P-numbered remediations, negative tests and regression evidence in the signed release.
ReDoS and parser resource exhaustion
P-09, P-19, P-33, P-43 and P-49 bound line length, allocation, regex work, output, concurrency and procfs scanning.
Symlink, hardlink and TOCTOU races
P-03, P-22, P-32 and P-34 bind sensitive work to verified files, owners and inodes instead of reusable paths.
Update and remote-source substitution
P-02, P-05, P-15, P-16, P-18, P-40 and P-42 authenticate releases, constrain archives and retain a last-known-good state.
XSS, CSRF, MIME and panel-authorisation abuse
P-10, P-11, P-31, P-36, P-38 and P-51 protect rendering, state changes, templates, webroots and native panel permissions.
Cluster spoofing, replay and resource abuse
P-20 authenticates and frames cluster traffic, detects replay and applies strict connection, message and work limits.
Process identity and accounting bypass
P-44 through P-50 defend against PID reuse, procfs field shifting, PGID/SID confusion, pignore abuse and unsafe lock recovery.
Firewall state loss and policy bypass
P-17, P-35, O-02 and O-03 make rule changes transactional and preserve reply traffic, rollback state and Docker-owned policy.
DNS trust-boundary and cache confusion
P-27 through P-30 separate display data from authorisation, canonicalise PTR values and bound resolver work and caches.
DCSF
Security architecture layers
The fixes combine into a coherent model for release integrity, untrusted input, privilege boundaries and active firewall state.
Signed distribution
Pinned RSA-3072 trust, SHA-256-signed manifests, strict HTTPS and explicit rollback checks protect the release path.
Bounded log parsing
Length, record and work limits prevent untrusted log input from consuming unbounded parser resources.
Privilege boundaries
Sensitive operations use validated arguments, controlled environments and checked identity transitions.
Remote input validation
Blocklists, archives and templates are accepted only through canonical URLs and verified transport.
Filesystem race resistance
No-follow handling, ownership checks and inode binding reduce symlink, hardlink and replacement races.
Transactional firewall state
Candidate rules are validated before activation, with controlled recovery if application fails.
Authenticated clustering
Cluster messages are authenticated, replay-aware, framed and subject to strict resource limits.
DNS trust and caching
Resolver responses are bounded, validated and cached without turning stale data into silent trust.
Per-vhost web overload correlation
WebGuard correlates bounded causal evidence outside the LFD regex loop and starts disabled in report mode.
DCSF
Evidence, not declarations
Each remediation is paired with negative tests, regression coverage and checks on supported operating-system families.
Threat model
Identify the input, trust boundary and failure consequence.
Attack test
Reproduce abuse in a controlled environment.
Remediation
Apply the smallest change that removes the vulnerability class.
Regression
Automate the evidence that prevents recurrence.
DCSF
Email the DCSF teamReport a suggestion or technical problem
Send DCSF suggestions, compatibility reports and reproducible technical problems to dat@etop.pl.
DCSF
Questions operators ask
Key information about the current production release.
What is AI System Scan?
An optional quick or deep security review of a bounded local snapshot. It is disabled by default and requires your own OpenAI API key. Results must reference supplied evidence IDs, remain advisory and do not automatically run repairs.
Is AI System Scan included in the free software price?
The DCSF software remains free under GPLv3, at USD 0. Optional OpenAI API usage is billed separately to the administrator’s API account. Selected diagnostic data is sent to OpenAI; store=false is not a Zero Data Retention guarantee.
Is DCSF the latest hardened CSF/LFD release from DataHouse?
Yes. DH20.29 is the latest hardened release in the DCSF line. It maps to signed technical package 15.10.32, carries 51 verified security remediations and passed all 77 release gates.
How does DH20.29 repair the required JSON::PP module?
RPM systems select the signed perl(JSON::PP) capability and Debian systems select libjson-pp-perl. cPanel uses its validated private Perl and matching cpanm; system CPAN remains disabled unless the operator explicitly supplies --allow-cpan-fallback.
How does DH20.29 load the OLSPanel action policy?
The backend uses the explicit shared path /usr/local/csf/lib/ConfigServer/panel-action-policy.json with require_trusted => 1. The complete parent chain and policy file must remain root-controlled and non-writable.
How does DH20.29 validate the real OLSPanel backend?
After generic installation and before publishing or restarting panel integration, the adapter runs perl -T -c and sends a bounded read-only binary request through the actual taint-mode backend. The response is limited to 16 MiB and must contain the DCSF interface marker.
How does DH20.29 protect administrator reauthentication?
Protected OLSPanel actions use a dedicated modal with a bounded type=password field instead of window.prompt(). Escape, cancellation and backdrop cancellation are supported, and the visible field is cleared immediately when the protected request receives the credential.
How does DH20.29 repair OLSPanel logs and action results?
Search System Logs and Watch System Logs accept only a one-to-twenty digit nocache value and always clear their progress state. Deferred, deduplicated _self navigation preserves results after Quick Allow, configuration save, Search for IP and Firewall Allow.
How does DH20.29 keep OLSPanel action results visible?
The action iframe stays between 640 and 1,200 pixels, scrolls internally and returns to its top after every navigation. Search for IP, Firewall Allow, Watch System Logs and the centered masked reauthentication modal therefore remain inside the visible operator viewport.
How does DH20.29 validate OLSPanel assets?
OLSPanel images, including csf.svg, are served from the authenticated package tree at /usr/local/csf/lib/webmin/csf/images.
How does DH20.29 protect OLSPanel CSF configuration?
Before package installation, the adapter performs a read-only metadata preflight for /etc/csf, /etc/csf/csf.conf and /etc/csf/csf.cloudflare. It rejects symlinks, unsafe hard links and unsafe metadata with an exact-path diagnostic, then normalizes the directory to root:root 0700 and protected files to root:root 0600 without changing existing contents.
Which control panels does DCSF support?
DCSF supports OLSPanel, cPanel & WHM, DirectAdmin, CyberPanel, CWP, InterWorx, VestaCP and Webmin, plus a generic mode for supported RHEL- and Debian-family Linux servers.
What bugs and exploit classes were fixed?
The public register covers command and argument injection, ReDoS and resource exhaustion, file races, update-chain substitution, web-panel abuse, cluster spoofing and replay, process identity bypasses, DNS trust errors and firewall-state loss.
What is WebGuard?
WebGuard is an optional, disabled-by-default service that correlates costly or stalled requests with saturation of the same canonical virtual host. DH20.29 retains bounded replay, isolated OpenLiteSpeed log collection and temporary exact-IP, listener-port-specific enforcement.
Can I download DCSF today?
Yes. DH20.29 is public and maps to the signed DCSF 15.10.32 package. The bootstrap verifies every trust-bearing artifact before installation.
How does the published fix count compare with cPanel CSF and Aetherinox CSF?
DCSF publishes 51 individually verified security remediations plus three operational controls. cPanel does not disclose a fix count for its targeted 16.31-1 security release. The Aetherinox 15.10 release summary lists 11 fix items, including two directly focused on XSS or unsafe input rendering; these release-note items are not equivalent to DCSF security gates.