LUCEE · INCIDENT REPORT
Administrator outage on 10.0.1.30
Hi
Is someone familiar with the inside of Lucee? I would never been able to fix it by myself. Is it worth reporting it? What are your opinions on this?
It was after an update via lucee server admin.
Core 6.2.9.4 · 27–28 Oct 2026 · hosted sites unaffected
The Administrator is working again. Full root-cause below. Two independent bugs were stacked inside the extension your 27.10 update installed — fixing the first exposed the second, which is why early attempts looked like they failed. The hosted CFML sites were never affected.
1 · ESAPI EncodeForURL (admin_layout.cfm:17)
The admin layout calls EncodeForURL() on every page and pins it to OSGi bundle esapi.extension version 2.6.0.1, class org.lucee.extension.esapi.functions.EncodeForURL(old namespace). After the update the only ESAPI jars present were 2.2.4.15 (old namespace class) and 3.0.0.15 (new guard.functions namespace) — no jar reported 2.6.0.1, so Felix couldn’t satisfy the pin → ClassNotFoundException. Editing the on-disk esapi-function.fld did nothing because the compiled admin carries its own 2.6.0.1 pin.
2 · dateAdd invalid datepart (web.cfm:96)
invalid datepart identifier [0] for function dateAdd Occurred in /admin/web.cfm: line 96, called from /admin/server.cfm: line 7 at lucee.runtime.functions.dateTime.DateAdd._call(DateAdd.java:102) at web_cfm$cf.call(/admin/web.cfm:96)
Line 96 builds the admin session/application timeout via CreateTimeSpan(...) → dateAdd. Admin 1.0.0.9 passes a numeric 0 as the datepart. Verified on the box: dateAdd("n",30,now()) works; dateAdd(0,30,now()) fails on both 6.2.9.4 and 6.2.5.48. So it’s the admin extension 1.0.0.9, not the new core. The previous admin (1.0.0.7, since Mar 2026) didn’t do this — hence it worked before.
Why version-swapping didn’t stick
The on-box 1.0.0.5.lex is an empty metadata stub (no templates); the working 1.0.0.7 was overwritten and isn’t locally recoverable. Lucee re-installs the highest availableadmin on each restart, so while 1.0.0.9 sat in extensions/available/ every restart re-deployed its buggy compiled LAR.
What I changed (reversible)
- ESAPI: built
esapi.extension-2.6.0.1.jarfrom the on-box2.2.4.15jar (which has the exact class the admin pins), re-versioned to 2.6.0.1 so Felix resolves it. Verified at runtime. - Admin: removed the 1.0.0.9
.lexfromavailable/+ its installed.mf/.lexso it stops re-installing; repinned in config; cleared admin LAR + Felix/cfclasses caches; restarted. - Also: fixed a stale ESAPI manifest; temporarily pinned core to 6.2.5.48 to test, then restored 6.2.9.4 (wrong hypothesis, reverted).
Caveat — load-bearing tape, not a clean state.
The fix relies on a hand-crafted 2.6.0.1 jar and on 1.0.0.9 being suppressed. A future Lucee update or an admin “install/update extension” could re-introduce the bug. Please do a proper reinstall when convenient.
Verified
- Service Running; hosted sites HTTP 200; ESAPI resolves; no admin errors in
out.logsince restart. - You confirmed the Administrator loads and works in the browser.
Paths forward
- Recommended: clean reinstall of the Administrator extension from Lucee’s update server (box has internet) to replace the compiled admin and drop the synthetic-jar dependency. If upstream still ships 1.0.0.9 with the bug, combine with #2.
- Report/track the
dateAdd(0)admin bug upstream (admin 1.0.0.9 + core 6.2.9.4). - Plan a coordinated core+extension update in a maintenance window, ideally on a staging clone; snapshot
C:\luceefirst. - Optional: bytecode-patch
web_cfm$cf.classto use a valid datepart — robust but a hack; only if reinstall isn’t possible. - Housekeeping once stable: remove the synthetic 2.6.0.1 jar + backup/cache folders.
Backups on box: esapi-fix-backup-*, core-pin-backup-*, admin-repin-*, admin-kill109-*, esapi-261-backup-*, plus renamed cache dirs. Fully reversible.