DirectAdmin 1.707

fln

Administrator
Staff member
Joined
Aug 30, 2021
Messages
1,448
We are happy to announce the release of DirectAdmin 1.707.

A full release change log is here:

DirectAdmin 1.707


The update should be automatically available for all installations subscribed to the current release channel.

We appreciate all the feedback on forums and issues reported in the ticketing system.

Thanks!
 
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 ?
 
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: 29
@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...
 
@ofisimo, could you please open a support ticket so we could investigate your server?

@unihostbrasil, we will keep the messenger/captcha service (only remove the vulnerable execution mode which is not enabled by default) but we really do not recommend using it.
 
It would already be a significant improvement if there were an "Exclude" button next to each hostname in the DNS list. With a single click, the selected hostname could then be moved directly to the Skip DNS Names list. (screenshot)
 

Attachments

  • Scherm­afbeelding 2026-08-07 om 14.31.39.png
    Scherm­afbeelding 2026-08-07 om 14.31.39.png
    156.9 KB · Views: 24
Hello,

ACME Settings page.

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



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?
I am experiencing the exact same issue when I'm using evo skin, which started happening after a recent update. My domain is hosted on Cloudflare, so I tried using the DirectAdmin Cloudflare API template by entering my API Token to update it. However, I keep running into the same error, and now even the Cloudflare API template is completely unusable. I really hope this can be fixed or added back.

Previously, I could use ssl templates from multiple providers, such as Cloudflare API and mydns.jp. However, they are all gone now, and I can only see this error

I wish I could downgrade to the previous version of ssl templates so that I could at least use it or we can change new version of old version to keep it. Right now, absolutely nothing is working


Snap1.jpg
 
Last edited:
AI Summary related to what ASUS and ofisimo shared.

ACME Settings page crashes in Evolution on 1.707 when the domain conf lacks acme_enabled (affects ~90% of pre-existing domains)

Environment:
DirectAdmin 1.707 (build dfe8f827), CloudLinux 9, Evolution skin. Reproduced across 9 independent servers.

Symptom: Opening ACME Settings for a domain shows: Unable to retrieve data due to the following reason: "A <SelectItem /> must have a value prop that is not an empty string..." — Retry does nothing.

Root cause (no root access needed to verify): the page crashes for every domain whose data/users/USER/domains/DOMAIN.conf does not contain the acme_enabled= key. That is the normal state for any domain that never went through the new ACME enablement — on our servers that's ~90% of all domains (6,042 of 6,705 across 9 boxes). Domains that do have acme_enabled=yes render the page fine.

Repro: take any domain conf without acme_enabled (or remove the key on a test domain) and open ACME Settings in Evolution on 1.707 → crash.

Workaround per domain: run /usr/local/directadmin/scripts/letsencrypt.sh request DOMAIN (proper enablement — writes acme_enabled=yes and provisions), or append acme_enabled=yes to the domain conf. Both make the page load again.

Suggested fix: the frontend Select should fall back to a default when acme_enabled is absent/empty (it's the majority state on upgraded servers), and Retry should re-render after the fix.
 
@Zhenmue, stop spamming the forum with AI hallucinations (slop). Your answer is completely wrong. Missing config entry has nothing to do with this error. Users to do NOT NEED to enable new system for the ACME settings page to work.

You message here is outright harmful. Please do post anything you have not verified manually.



@ofisimo, @ASUS, could you please open a support ticket so we could inspect the configuration of you server.

If I had to guess, I think it will have something to do with the malformed data/admin/dnsproviders.json file. By malformed I mean not just missing file or invalid JSON. I mean having valid structure with empty dictionary keys. We would really like to find out how this happened. The dnsproviders.json file can be regenerated (synced with lego tool) with the da build lego command.
 
Last edited:
Back
Top