DirectAdmin 1.707

Hello,

A stable release is still 1.705? Not 1.706?

Bash:
# dig +short -t txt stable-version.directadmin.com
"v=1.705&commit=610f28d2f77c98e008717f99284d2919229a5f12&rt=2026-07-23T14:29:00Z&du=120h&df=12h"
 
Yes. The stable release channel is still 1.705. We are still considering if we should cherry-pick some changes from 1.707 into 1.706 before pushing it to stable, or keep stable locked to 1.705 for one more release.
 
That's good. I believe the stable version should be updated much less frequently than it is now, especially with things that are breaking changes in some environments. Alternatively, something like an LTS should be created.
 
Last edited:
A new build is released with two changes:
  • The MX records page was not visible for users with blocked dnscontrol in user.conf. It will be visible now.
  • Webserver configuration logic that selects which certificate to use has a legacy fallback to use the main domain name certificate even if certificate does not cover the main domain name. It can be useful for non-standard configurations when main domain website is not served by DA server.
 
We've been waiting for the new stable release so we can update nginx to 1.31.3. It was released on july 15 and I believe we still cannot update it for DA unless we use the mainline release?

I was happy to hear a new version has been released but now it seems we still cannot install the nginx security update?

What's the most sane way for this? Should we run mainline if we want quick security fixes?
 
We've been waiting for the new stable release so we can update nginx to 1.31.3. It was released on july 15 and I believe we still cannot update it for DA unless we use the mainline release?

I was happy to hear a new version has been released but now it seems we still cannot install the nginx security update?

What's the most sane way for this? Should we run mainline if we want quick security fixes?

change version manually in Custom Build > Versions ? I never tested it with Ngjnx but I change versions on the LiteSpeed Enterprise server as build 0 which came with previous release have issues with cleaning cache so manually switched to build 1 as recommendation from LS Support before DA pushed the current one with build 6 ...

===============

Any way I'm here to ask something else

@fln - cpanel released security update for theri csf fork https://support.cpanel.net/hc/en-us/articles/42503837957015-Security-CSF-Security-Release ( I notice we too have CSF update) are we affected / patched ?
 
@DanielP, the default DA installation is not affected. There is a vulnerability in the CSF captcha/messenger feature. Users who manually enabled it are effected. We are planing to release new CSF build with captcha/messenger feature completely removed.
 
Hello,

ACME Settings page.

The problem affects all hosting accountsSSL Certificates → ACME Settings, the following error is displayed:

Unable to retrieve data due to the following reason:
"A <SelectItem /> must have a value prop that is not an empty string. This is because the Select value can be set to an empty string to clear the selection and show the placeholder."
Click "Retry" to try again.

As a result, the ACME Settings page does not load.

Additional information:

  • The issue started after updating DirectAdmin.
  • It affects every hosting account on the server.
  • The problem occurs in different browsers as well.
  • Browser cache has been cleared, but the issue persists.
  • I have attached a screenshot of the error.

Has anyone else encountered this issue? Is this a known bug in the latest DirectAdmin release, or is there any workaround available?
 

Attachments

  • Screenshot.png
    Screenshot.png
    80.5 KB · Views: 11
@DanielP, the default DA installation is not affected. There is a vulnerability in the CSF captcha/messenger feature. Users who manually enabled it are effected. We are planing to release new CSF build with captcha/messenger feature completely removed.
This feature is very useful, as it allows users to unblock their own IPs, thereby reducing the demand on technical support. Please try to keep it.
 
This feature is very useful, as it allows users to unblock their own IPs, thereby reducing the demand on technical support. Please try to keep it.
True, for some users it's good to know they are blocked and what to do. On the other hand, you also get hit by ip's that are blocked for a good reason so you're not really blocking bad actors.
 
True, for some users it's good to know they are blocked and what to do. On the other hand, you also get hit by ip's that are blocked for a good reason so you're not really blocking bad actors.
Absolutely. But our experience has been very positive. We manually review every unblocking action performed via this feature, and to date, there hasn't been any misuse—only legitimate users. This is likely because most brute-force attempts are carried out by bots; when an IP gets blocked, they simply move on to the next target.
 
Absolutely. But our experience has been very positive. We manually review every unblocking action performed via this feature, and to date, there hasn't been any misuse—only legitimate users. This is likely because most brute-force attempts are carried out by bots; when an IP gets blocked, they simply move on to the next target.
True, but a bot doesn't get blocked if csf returns a messenger page and thus doesn't move on (many bots are simply stupid) and keep hitting you with all kinds of exploits that obviously don't work but they also don't get a timeout. They're not blocked, they're rerouted to a another service.
The misuse is in the part that bot's can keep hitting your server, not valid users who request removal from the blocklist.

Pro's and Con's, ey...
 
Back
Top