DH20.29 release register

51 verified CSF/LFD bug and exploit fixes in DH20.29

The public register documents 51 security remediations and three operational controls. DH20.29 adds WHM, LFD state and installer compatibility repairs without increasing that vulnerability count. The 77 passing Linux test files and completed canary are qualification evidence, not additional vulnerabilities.

DCSF

DH20.29: what changed

This release combines WHM context, LFD state and installer repairs with the regression fix found on canary. It supersedes DH20.28; the 51-item security register remains a separate count, without counting tests as vulnerabilities.

01

Validated WHM session context

The WHM CGI preserves the validated cp_security_token required by the native cPanel session. Existing request validation, taint mode and same-origin response boundaries remain in place.

02

Bounded LFD process-state compaction

LFD compacts csf.temppids within its existing size and record limits, using LF_FLUSH to age process records. Accumulated temporary state no longer prevents normal tracking from recording new process identities.

03

Permissions limited to public cPanel META modules

The compatibility repair sets appropriate permissions only for public cPanel META modules. It does not broaden access across private configuration or the complete cPanel tree.

04

Reliable reseller-file repair

DH20.29 safely repairs a missing final LF in csf.resellers and corrects the shell error found on the canary. DH20.28 / 15.10.31 is superseded because its reseller repair path was faulty.

05

Equivalent nftables policy comparison

The comparison accepts a different listing order for independent chains while preserving rule order inside each chain and the remaining policy checks. Reordering independent chains alone no longer causes a false policy mismatch.

06

77/77 Linux tests and a completed canary

Maintainer qualification passed all 77 Linux test files. The autossltest2 canary update completed with CSF/LFD active and configuration preserved. The separately checked production host has passed dry-run only; this is not a production-upgrade claim.

Models, data and API costs

Model choices offered by this release: gpt-5-mini, gpt-5.4-mini, gpt-5.6-terra. Availability depends on the administrator’s OpenAI API account.

Selected local security diagnostics are sent to OpenAI after activation. Recognised secret values are redacted, but this is not an anonymity guarantee. store=false is not a Zero Data Retention guarantee; the API account and provider data policies still apply. Optional API usage is billed separately from the free DCSF software. Findings need administrator review and do not guarantee that every security issue is detected.

OpenAI API data-retention policies

Retained installation and compatibility fixes
  • Native WHM Jupiter interface restored. DH20.27 fixed the cPanel regression where a standalone DCSF HTML document replaced the WHM page. DCSF renders through csf.tmpl and the native master_templates/master.tmpl, retaining panel navigation and responsive layout.
  • Taint-mode CGI and bounded template helper. The main CGI retains perl -T, request validation and same-origin responses. A fixed root:root 0700 helper uses cPanel private Perl and Cpanel::Template::process_template through list-form IPC::Open2. It clears interpreter-control environment variables, fixes PATH, accepts no path or template arguments and limits stdin to 32 MiB.
  • nginx is the client-address authority. For the verified cPanel EA-Nginx topology, SERVER="auto" selects nginx on public ports 80/443. Its structured edge access feed supplies the real client address. WebGuard does not trust arbitrary X-Forwarded-For values or infer clients from an ordinary Apache backend log.
  • Apache reports load, not a client to block. Apache listens on private ports 81/444. Its server-status and optional backend-role feed contribute overload evidence only. The local nginx peer 127.0.0.1 cannot become a blocking candidate. Unsupported or unverified proxy layouts are not assumed to have the same trust boundary.
  • One trusted library tree during diagnostics. A diagnostic run of an extracted signed package beside older cPanel CSF keeps the selected package libraries first. An exact legacy prepend of /usr/local/csf/lib reasserts the trusted source root and leaves installed libraries as fallback only. Normal installed execution is unchanged.
  • Native snapshot before migration. When iptables-save cannot export a known incompatible iptables-nft table, the cpanel-csf migration saves the complete nft list ruleset and exporter diagnostics with SHA-256 checksums. It proceeds only after proving the parallel legacy backend is inert and securing the exact RPM rollback package.
  • Bounded rebuild through trusted CSF. The bootstrap rebuilds only the incompatible standard filter, nat, mangle, raw and security tables in the ip and ip6 families through the already installed, trusted csf -r. Unrelated native tables are not selected for normalization.
  • Canonical policy check and automatic rollback. Canonical IPv4/IPv6 policies are compared before and after the rebuild. A missing table, semantic mismatch, interruption or later installation failure triggers restoration. Tests covered all ten standard tables, including a forced mismatch that restored the original policy and configuration.
  • Optional AI System Scan. AI System Scan adds quick and deep assessments to the DCSF administration interface. It is disabled by default and requires the administrator to configure a personal OpenAI API key and select a model.
  • Bounded evidence and private credentials. A single background scan collects a bounded local security snapshot, with limits on reads, processes, data size and execution time. The API key is kept in a separate root-only file and is never rendered back into the interface.
  • Findings tied to supplied evidence. OpenAI Responses API requests use store=false, no tools and strict structured output. Findings and recommendations must cite valid evidence IDs from the submitted snapshot. Results are advisory and do not automatically execute repairs.
  • Populated private AI state directories. The installer checks owner, group and permissions of private AI state directories without requiring a directory link count of one. Existing subdirectories on ext filesystems no longer cause a false installation refusal; unsafe ownership or permissions still stop installation.
  • Conservative migration gates remain. An exit code 0 from an exporter is not proof of completeness. Migration still refuses unknown diagnostics or active parallel legacy policy. An active standard nftables table missing from the normalized snapshot or a changed canonical policy triggers rollback.
  • Separate procfs context budget. Contextual identity checks have a separate, bounded procfs scan budget. Hosts with many processes no longer generate false excessive usage alerts from this budget collision; ordinary process, per-UID and global limits are not relaxed.
  • LFD active after production updates. After a successful production-profile update (TESTING=0), the installer restarts LFD and checks the result, including active service state on systemd. The new daemon code takes effect immediately; TESTING=1 installations are not started.
  • Bounded registration retry. Installation registration uses the extensionless HTTPS API with bounded retry and backoff. A transient failure can be retried without an unbounded wait; signed identity and source-address checks remain in force.
  • SELinux-aware installation. The installer checks SELinux state before using chcon. Disabled SELinux no longer produces misleading relabel warnings, while enabled systems retain context handling.
  • Native systemd handling. A systemd-only host no longer reports missing legacy SysV init files or tries to change ownership of files that are not installed. Legacy init remains supported.
  • Accurate Apache and ModSecurity checks. Inactive Apache and default ModSecurity log paths are informational. With systemd, actual service state is authoritative: Zimbra's private /opt/zimbra/common/bin/httpd is not mistaken for the system Apache service. Legacy init retains a process fallback.
  • Validated Zimbra mail transport. The canonical Zimbra sendmail symlink is recognized through the trusted-path check. This targeted compatibility repair does not make arbitrary symlinks trusted.

Linux release qualification: 77/77. Public-bootstrap checks: 85/85.

DCSF

Every security remediation in the signed release

The register covers command boundaries, parsers, files, remote sources, panels, clusters, processes, DNS and firewall state. Statuses are bound to the published package.

51All
51Implemented
51Verified
Filter by status
Visible items: 51
  1. P-01

    Isolate Messenger reCAPTCHA input from every root shell boundary

    Verified
  2. P-02

    Keep remote GLOBAL feeds data-only and unable to deliver advanced rules

    Verified
  3. P-03

    Protect Messenger files from symlink, hardlink and replacement races

    Verified
  4. P-04

    Parse CIDR /0 explicitly and permit it only through caller policy

    Verified
  5. P-05

    Require pinned RSA-3072 signatures, SHA-256-bound metadata and rollback checks for updates

    Verified
  6. P-06

    Harden the DirectAdmin privileged bridge and verify identity transitions

    Verified
  7. P-07

    Run privileged Perl entry points in taint mode with a minimal environment

    Verified
  8. P-08

    Generate a protected host-local key for the standalone interface

    Verified
  9. P-09

    Bound standalone UI workers, requests, searches, pre-authentication time and emitted output

    Verified
  10. P-10

    Add CSPRNG sessions, CSRF protection, secure headers and modern TLS to the standalone UI

    Verified
  11. P-11

    Encode untrusted output at the final rendering boundary in every UI adapter

    Verified
  12. P-12

    Classify Dovecot 2.4 success and failure variants without known false positives

    Verified
  13. P-13

    Ignore managesieve-login consistently in every applicable profile

    Verified
  14. P-14

    Restrict custom regex results to validated TCP or UDP ports from 1 to 65535

    Verified
  15. P-15

    Enforce HTTPS with certificate and hostname verification for remote sources

    Verified
  16. P-16

    Validate download status, size and format before atomic last-good replacement

    Verified
  17. P-17

    Propagate restore failures and retain the last working firewall state

    Verified
  18. P-18

    Extract ZIP blocklists with strict limits and atomic replacement

    Verified
  19. P-19

    Bound log records before regex processing and remove catastrophic patterns

    Verified
  20. P-20

    Authenticate, frame and resource-bound all cluster traffic

    Verified
  21. P-21

    Isolate LF_DIRWATCH offenders and recover monitoring automatically

    Verified
  22. P-22

    Apply LF_SCRIPT_PERM changes only to the verified open inode

    Verified
  23. P-23

    Keep secrets out of arguments, URLs, unsafe files and diagnostic bodies

    Verified
  24. P-24

    Use one strict canonical API for IPv4, IPv6 and CIDR normalization

    Verified
  25. P-25

    Validate the final mail envelope and invoke sendmail without a shell

    Verified
  26. P-26

    Resolve exact syslog user names, including names beginning with an underscore

    Verified
  27. P-27

    Separate display DNS data from security-authorisation cache state

    Verified
  28. P-28

    Match trusted hostnames only as exact names or DNS-label suffixes

    Verified
  29. P-29

    Canonicalise PTR data before cache, logs, mail, HTML or configuration use

    Verified
  30. P-30

    Bound DNS verification and caches by time, concurrency, size and complexity

    Verified
  31. P-31

    Allow privileged CyberPanel mutations only through protected POST actions

    Verified
  32. P-32

    Remove predictable and followable temporary files from every installer

    Verified
  33. P-33

    Prevent raw-byte record readers from splitting inside multibyte characters

    Verified
  34. P-34

    Register, authorise and bound every persistent store consumed by root

    Verified
  35. P-35

    Use one unambiguous transactional grammar for temporary firewall rules

    Verified
  36. P-36

    Render alert templates once and prevent untrusted MIME structure injection

    Verified
  37. P-37

    Drop Messenger v1 privileges irreversibly and close inherited descriptors

    Verified
  38. P-38

    Contain Messenger v2 and v3 webroots and generated webserver configuration

    Verified
  39. P-39

    Verify the Messenger identity and make each instance lifecycle transactional

    Verified
  40. P-40

    Build and install releases from a closed, verified artifact inventory

    Verified
  41. P-41

    Transport authenticated panel requests without invoking a shell

    Verified
  42. P-42

    Validate and install remote Geo and ASN datasets as one last-good transaction

    Verified
  43. P-43

    Bound log-record allocation before a complete attacker-controlled line enters memory

    Verified
  44. P-44

    Bind process actions to kernel identity rather than a reusable PID or socket inode

    Verified
  45. P-45

    Ensure fork-bomb handling never treats a session ID as a process-group ID

    Verified
  46. P-46

    Remove command text and custom pignore regexes as process identity or action authority

    Verified
  47. P-47

    Prevent attacker-controlled comm bytes from shifting procfs identity fields or hiding a process

    Verified
  48. P-48

    Prevent executable exceptions from bypassing accounting across UID, service or supervisor boundaries

    Verified
  49. P-49

    Bound procfs scanning per object, per UID and globally with cross-UID fairness

    Verified
  50. P-50

    Bound lock-hang recovery and never signal a target parsed from lock-file bytes

    Verified
  51. P-51

    Block secondary InterWorx NodeWorx accounts from DCSF unless they hold native firewall authority

    Verified
DCSF

DH20.29 closes the JSON::PP dependency without weakening trust

Package 15.10.32 adds JSON::PP to installer preflight and the os.pl runtime check while preserving the separation between system Perl, cPanel private Perl and explicit CPAN fallback.

01

Authenticated OS packages first

Outside cPanel, DCSF repairs the closed module list through exact RPM capabilities or Debian package mappings. DNF and YUM retain GPG verification, while APT rejects unauthenticated and insecure repositories.

02

Measured progress and re-verification

The installer inventories required modules before preflight and after repair. Attempts are bounded, must make measurable progress and succeed only when the entire closed list imports again.

03

CPAN only with explicit approval

The system CPAN fallback is disabled by default. The operator must pass --allow-cpan-fallback; DCSF uses a fixed HTTPS MetaCPAN mirror, closed module names and validated work directories.

04

cPanel private Perl boundary

On cPanel, DCSF always validates /usr/local/cpanel/3rdparty/bin/perl, derives the matching versioned cpanm and explicitly invokes it through that same private interpreter without mixing /usr/bin/perl libraries.

05

Required JSON::PP runtime

OLSPanel requires JSON::PP. RPM selects the signed perl(JSON::PP) capability, Debian selects libjson-pp-perl, cPanel uses private cpanm and system CPAN still requires explicit --allow-cpan-fallback.

Canary PASS: An earlier public --dryrun canary authenticated the release under test, selected the correct installer and left every regular file directly below /etc/csf byte-identical.

DCSF

DH20.29 keeps OLSPanel actions in the visible viewport

Package 15.10.32 bounds the iframe to 640–1,200 pixels, scrolls it internally and returns it to the top after navigation. The masked modal, Watch System Logs, Search for IP and Firewall Allow remain visible while trusted-policy and real-backend checks are retained.

01

Discovery without a false prerequisite

The modules directory is optional. Detection accepts only supported canonical roots and a safe root-owned /etc/olspanel/base_dir declaration.

02

Protected-configuration preflight

Before writing, the adapter only reads metadata for /etc/csf, /etc/csf/csf.conf and /etc/csf/csf.cloudflare. --dryrun executes the same checks without changing files.

03

Alias rejection and exact diagnostics

Symlinks, non-regular files, non-root ownership, group/world writable metadata and protected files with more than one hard link are rejected before installation with the exact failing path.

04

Content-preserving finalization

After installation, /etc/csf becomes root:root 0700 while csf.conf and csf.cloudflare become root:root 0600 with exactly one hard link. Existing contents remain byte-identical.

05

Authenticated missing file

If csf.cloudflare is missing, it may be installed only from the verified signed package; an existing file is not replaced.

06

No false success

The generic installer stops when recursive chmod or chown fails instead of continuing to a PASS message.

07

Controlled modules creation

A missing directory is created only during a real installation as root:root 0755. DCSF records privately that it created the path.

08

Conservative uninstall

Uninstall removes the parent only when DCSF created it and it remains empty. Foreign or non-empty content is preserved.

09

JSON::PP runtime dependency

Preflight and the os.pl runtime check require JSON::PP. Repair uses signed RPM capability perl(JSON::PP), Debian package libjson-pp-perl, cPanel private cpanm or the explicitly enabled system CPAN fallback.

10

Isolated backend compilation

After generic installation but before publishing or restarting panel integration, the adapter runs an isolated perl -T -c backend check. Failure stops OLSPanel integration.

11

Correct panel assets

OLSPanel serves images from the authenticated /usr/local/csf/lib/webmin/csf/images tree, where the signed package installs assets including csf.svg.

12

Explicit trusted policy

The backend loads /usr/local/csf/lib/ConfigServer/panel-action-policy.json with require_trusted => 1 instead of using the CyberPanel-specific default path. The complete parent chain and file must be root-controlled and non-writable by others.

13

Real backend-frame validation

The installer sends a bounded read-only binary request through the actual taint-mode backend. The response may not exceed 16 MiB and must contain the DCSF interface marker before integration is published or restarted. After the extmail.uck.katowice.pl upgrade, the complete Django-to-Perl-backend path returned HTTP 200.

14

Masked administrator reauthentication

Protected actions use a dedicated modal with a bounded type="password" field instead of window.prompt(). Escape, the cancel control and backdrop cancellation safely stop the operation, and the visible field is cleared immediately after the credential is handed to the request.

15

Working system-log tools

Search System Logs and Watch System Logs accept only a one-to-twenty digit nocache value. Progress ends after every response, failed requests display their HTTP status, and live search and watch checks returned HTTP 200.

16

Visible protected-action results

Intercepted navigation is deduplicated, deferred to the next event turn and explicitly submitted to _self with visible progress. Quick Allow and configuration save retain a complete nonempty response instead of an empty frame.

17

Search for IP and Firewall Allow

Tests through the real Perl backend found the newly added address, displayed the Firewall Allow list and returned normal Done and Return controls. The temporary entry was removed and the final csf.allow digest exactly matched its pre-test value.

18

Bounded scrollable action viewport

The action iframe stays between 640 and 1,200 pixels, scrolls long content internally and returns to the top after every navigation. The live test kept the outer page at 1,000 pixels with scroll position zero, so Search for IP, Firewall Allow, Watch System Logs and the reauthentication modal remained visible.

DCSF

Three public operational controls

Beyond the 51 remediations, the register covers installation profiles, CC_DENY reply handling and Docker policy preservation. DH20.29 qualification contains 77 gates, so that number is not presented as a vulnerability count.

O-01

Require an explicit testing or production installation profile and expose testing mode in health checks

Verified
O-02

Preserve replies to locally initiated connections under CC_DENY without admitting new inbound traffic

Verified
O-03

Preserve Docker-owned chains and DOCKER-USER policy through firewall restart and rollback

Verified
Released

DH20.29: 77 of 77 release gates passed

DCSF 15.10.32, OLSPanel configuration finalization, Perl dependency repair, WebGuard, bootstrap, distribution integrity and the responsive interface were verified. P-01–P-51 remains the public security-remediation register.

Download release