[#47845] - [5.4] Replace MD5 with HMAC-SHA256 in ApplicationHelper::getHash()
- Closed
- 27 May 2026
- Medium
- Build: 5.4-dev
- # 47845
- Diff
- ManhThuan:security/replace-md5-hmac-sha256-gethash
User tests: Successful: Unsuccessful:
Pull Request resolves # .
- I read the Generative AI policy and my contribution is either not created with the help of AI or is compatible with the policy and GNU/GPL 2 or later.
Summary of Changes
Replace md5(secret . seed) with hash_hmac('sha256', $seed, $secret) in
ApplicationHelper::getHash().
This method generates CSRF form tokens, user activation tokens, and password
reset tokens. The previous implementation used MD5 (broken since 2004, RFC 6151)
with plain concatenation, which is vulnerable to length extension attacks.
HMAC-SHA256 (RFC 2104) is the correct construction for keyed hashing.
Testing Instructions
Run the new unit test:
vendor/bin/phpunit tests/Unit/Libraries/Cms/Application/ApplicationHelperTest.php
All 5 tests should pass. No functional changes — tokens are generated fresh
at runtime so no migration is needed.
Actual result BEFORE applying this Pull Request
getHash() returns md5($secret . $seed) — a 32-char hex string using broken MD5.
Expected result AFTER applying this Pull Request
getHash() returns hash_hmac('sha256', $seed, $secret) — a 64-char hex string
using HMAC-SHA256, resistant to length extension attacks.
Link to documentations
Please select:
- Documentation link for guide.joomla.org:
- No documentation changes for guide.joomla.org needed
| Status | New | ⇒ | Pending |
joomla-cms-bot
- | Category | ⇒ | Libraries Unit Tests |
| Labels |
Added:
Unit/System Tests
PR-5.4-dev
|
||
| Status | Pending | ⇒ | Closed |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2026-05-27 17:20:41 |
| Closed_By | ⇒ | Hackwar |
Hello @ManhThuan, I understand what you are trying to do here, unfortunately this is a hard backwards compatibility break. It is such a hard b/c break, that we wont be adding this to Joomla. Yes, MD5 is broken, but contrary to what the method claims, it also does not return a secure hash in any way, shape or form. This method is used to name several identifiers for cookies, etc. and if we merge your proposal, it would mean that for example all sessions and all cookie consents would be invalidated. Besides that, the length of the hash changes as well and we have to assume that there are several cases where this is used with fixed-length database columns or string checks. If you want to provide HMAC-SHA256, you would have to provide a new method, but we still couldn't switch the usage in our code to use that new method because of the above reasons.
For these reasons, I'm closing this PR. Thank you for your work, but unfortunately we wont be able to accept this. We would be happy if you would contribute again in the future.