/api/v1/chat.postMessage: bad request

Description:

We send messages to rocket.chat using api via a bash script that acts in a way like:

curl \
        -s -q \
        --connect-timeout 10 --max-time 20 \
        -H "X-Auth-Token: XXX" \
        -H "X-User-Id: XXX" \
        -H "Content-type: application/json" \
        "https://ROCKET_CHAT_SERVER/api/v1/chat.postMessage" \
        -d '{"channel":"'"${CHANNEL}"'","alias":"'"${NICKNAME}"'","avatar":"'"${ICON_URL}"'","text":"'"${TEXT}"'"}'

So, it is enough to do:

export NICKNAME="myname"
export TEXT="simple text"
export ICON_URL="https://i.imgur.com/Hg2VK4Z.png"
./script

In the recent past we found in the rocket.chat http logs something like:

$IP - - [19/Dec/2023:23:58:57 +0100] "POST /api/v1/chat.postMessage HTTP/1.1" 400 839 "-" "curl/7.29.0" "-"

So after a bit of investigation I discovered that when TEXT comes from a shell command, and there are spaces, it does not work; example:

export TEXT="a b" -> works

mkdir -p /tmp/dir ; cd /tmp/dir ; touch a ; export TEXT="$( ls )" -> works
mkdir -p /tmp/dir ; cd /tmp/dir ; touch a b ; export TEXT="$( ls )" -> DOES NOT WORK

NOTE: we keep logs for one month, so I'm not able to say in which version the regression happened, but this is not just the 6.5.0 update since it was released on Dec 1, while I have records of this issue also in November.
In the past, that way of sending messages always worked for us, no matter of the TEXT content.

Server Setup Information:

• Version of Rocket.Chat Server: 6.5.0
• Operating System: Gentoo
• Deployment Method: tar
• Number of Running Instances: 1
• DB Replicaset Oplog:
• NodeJS Version: 14
• MongoDB Version: 5.0

Start with the curl invocation for /api/v1/chat.postMessage and reproduce the failure using TEXT populated by $(ls) when filenames contain spaces. Compare the successful and failing JSON requests and inspect the chat.postMessage API entry point. Done means the reproduced request is handled correctly and a regression test covers this TEXT content.