Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

[Bug] mqadmin createUser/updateUser trim the ACL password, storing a secret the caller never typed

Open Beginner friendly
  • Is something wrong?
#11,446 1 comment 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

@iloveeyjafjalla is already working on this.

Since Oct 16, 2026.

  • #11447 by @iloveeyjafjalla — open

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
78/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
java
Domain
authentication, cli

Research direction

The password trim is in the createUser and updateUser mqadmin subcommands, where the password option value is passed through StringUtils.trim before the admin API call. Start with the tests CreateUserSubCommandTest.testCreateKeepsThePasswordVerbatim and UpdateUserSubCommandTest.testUpdateKeepsThePasswordVerbatim, which currently fail. Done when the password reaches the mocked DefaultMQAdminExt unchanged, while the username, user type and broker address are still trimmed.

Written by the indexing model from the issue text.

Description

Before Creating the Bug Report
  • I have searched the open issues of this repository and believe that this is not a duplicate.
  • This is a defect in Apache RocketMQ, not a usage question.
  • I can reproduce this on the current develop branch.
RocketMQ Version

develop @ 5d68880cbdfa5c6d87b5681c5eb3684df0e18ef8 (the revision this was verified on)

Describe the Bug

mqadmin createUser -p <secret> and mqadmin updateUser -p <secret> run the password through StringUtils.trim before calling the admin API:

String username = StringUtils.trim(commandLine.getOptionValue('u'));
String password = StringUtils.trim(commandLine.getOptionValue('p'));   // <-- the secret
String userType = StringUtils.trim(commandLine.getOptionValue('t'));

A secret is a payload, not a name. RocketMQ stores the secret it is given (AuthMigrator copies accessConfig.getSecretKey() into the user record, User.of(accessKey, secretKey, ...) in the authentication manager) and every client is authenticated against exactly that string, so leading or trailing whitespace is part of a legal secret - and secrets pasted from a vault or a file routinely carry one.

The CLI silently stores the trimmed value, so:

  • mqadmin createUser -u bob -p " s3cret " -b 127.0.0.1:10911 stores s3cret;
  • every client that presents the real secret " s3cret " is rejected as unauthenticated, and nothing in the CLI output or the broker log points at the difference;
  • through the admin API the same secret is stored verbatim, so the CLI and the API disagree about the same user.

The neighbouring command sendMessage carried the same shape for the message body until #11414 dropped its .trim().

Steps to Reproduce
  1. mqadmin createUser -u bob -p " s3cret " -b 127.0.0.1:10911 (or the same through updateUser).
  2. Read the stored user back (mqadmin getUser -u bob -b 127.0.0.1:10911): the stored secret is s3cret, not the string that was passed.
  3. Authenticate one client with " s3cret " and one with s3cret: the first is rejected, the second succeeds.

A unit test makes the same point without a broker: the mocked DefaultMQAdminExt receives "s3cret" for the argument " s3cret ":

CreateUserSubCommandTest.testCreateKeepsThePasswordVerbatim:65 expected:<[  s3cret  ]> but was:<[s3cret]>
UpdateUserSubCommandTest.testUpdateKeepsThePasswordVerbatim:65 expected:<[ p@ss word ]> but was:<[p@ss word]>
What Did You Expect to See?

The password reaches createUser / updateUser exactly as the operator passed it. The username, the user type and the broker address keep their trim.

What Did You See Instead?

Both commands trim the secret, so a secret with leading or trailing whitespace cannot be provisioned through mqadmin at all, and the mismatch only shows up later as an authentication failure.

Dominant language
Java
Stars
22.6k
Forks
12k
Avg merge
6d 23h
Merged PRs (30d)
16

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from apache/rocketmq

All issues in apache/rocketmq

Similar issues

More Java issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.