Bug #87917


Bot manipulated form fields lead to exception

Added by Harald Holzmann over 5 years ago. Updated over 2 years ago.

Should have
Target version:
Start date:
Due date:
% Done:


Estimated time:
TYPO3 Version:
PHP Version:
Is Regression:
Sprint Focus:



I found out that if you manipulate the hidden fields of a form, typo3 raises an error. Error message is "Uncaught TYPO3 Exception: #1320830276: A hashed string must contain at least 40 characters, the given string was only 6 characters long. | TYPO3\CMS\Extbase\Security\Exception\InvalidArgumentForHashGenerationException thrown in file ......../htdocs/typo3_src-8.7.24/typo3/sysext/extbase/Classes/Security/Cryptography/HashService.php in line 90" or "Uncaught TYPO3 Exception: #1320830018: The given string was not appended with a valid HMAC. TYPO3\CMS\Extbase\Security\Exception\InvalidHashException thrown in file| ......./htdocs/typo3_src-8.7.24/typo3/sysext/extbase/Classes/Security/Cryptography/HashService.php in line 94".

If a bot or user manipulates for example the hidden trustedproperties field "name="tx_vayoga_contact[__trustedProperties]" or "name="tx_vayoga_contact[__referrer][@request]".

In my opinion the exception should be checked before. For example if the string is long enough or can be hmac parsed. But to be honest it spams the protocol. You cannot focus on the real issues.

What you think about it?

Kind regards,

Related issues 2 (0 open2 closed)

Related to TYPO3 Core - Feature #90134: Send 400 - BAD REQUEST on invalid hmacs from extbase formsClosed2020-01-16

Related to TYPO3 Core - Bug #93667: Disable logging of invalid requests due to manipulated form submissionsClosed2021-03-06

Actions #1

Updated by Georg Ringer over 5 years ago

  • Description updated (diff)
Actions #2

Updated by Georg Ringer over 5 years ago

  • Status changed from New to Rejected

Thanks for creating the issue. We don't see this is problem as the exception is correct, the request must fail if the hmac is wrong.

If you have too many issues like that, try to block the bot in your firewall, waf or htaccess.

Actions #3

Updated by Daxboeck no-lastname-given about 5 years ago

  • Target version set to next-patchlevel
  • TYPO3 Version changed from 8 to 9

Dear Georg Ringer,

I strongly disagree !

It is annoying to have the error log flooded with HMAC "errors".
Any URL sent by external sources must never result in "errors" at all because this is no system and no internal plugin error.
The purpose of "errors" in the log is to detect bugs in the system itself and to be able to fix them.
It cannot be the purpose to have something in the error log, which you cannot avoid by fixing extensions.

If you think that all these HMAC errors should be reported somewhere, then they belong to a separate log file which preferably could be read by tools like "denyhosts" and then can be used to automatically block the source.

The current solution which floods the log of larger TYPO3 systems like ours is simply idiotic.

Best regards,


Actions #4

Updated by Christian Eßl over 4 years ago

I think that throwing an exception in this case (that is logged) isn't the best solution.

What do you think about returning a status code 400 - BAD REQUEST in this case?

Actions #5

Updated by Christian Eßl over 4 years ago

  • Related to Feature #90134: Send 400 - BAD REQUEST on invalid hmacs from extbase forms added
Actions #6

Updated by Peter Linzenkirchner about 4 years ago

I strongly support the suggestion of Christian returning a Bad Request instead of an exception.

My reasons:
- the log is really flooded with these exceptions
- in the error log i cant find the IP of the bot so it is quite difficult to search the IP in the server logs for every single error log entry in order to block it.
- i cant see a possiblity to automate this process: exception -> looking for IP -> adding to blacklist of server side spam filter ...


Actions #7

Updated by Thomas Sam Wittich over 3 years ago

Same issue here.
Don't understand why some insist it's correct thowing the exception.

Please understand that the suggested solution to block the "requesting bots" is not a real solution: Had random IP accessing the form, Tokyo, Montreal, Kopenhagen, so... no single rule will match.

How to suppress this message?

Can we please fix this?

Thank you, Thomas

Actions #8

Updated by Torben Hansen over 3 years ago

  • Related to Bug #93667: Disable logging of invalid requests due to manipulated form submissions added
Actions #9

Updated by l j almost 3 years ago

  • TYPO3 Version changed from 9 to 8

The bug is still not fixed. I have 30 log entries per day.

Dear developers, are you planning a fix?

Actions #10

Updated by Torben Hansen almost 3 years ago

You changed the TYPO3 version from 9 to 8. Does that mean, that you experience the bug in TYPO3 8.7?

Actions #11

Updated by Rozbeh Chiryai Sharahi over 2 years ago


in case someone comes from google and has a controller with a form integrated:

It is possible to catch the exception and render for instance a 404 instead:

    // This code goes into your controller

    public function processRequest(RequestInterface $request, ResponseInterface $response)
        try {
            parent::processRequest($request, $response);
        } catch (Throwable $exception) {
            // Sometimes bots edit the trusted properties
            // In that case we get an HMAC error
            // Here we catch it
            if(strpos($exception->getMessage(), 'The HMAC') === 0) {
            throw $exception;

    public function render404Page(): void
        throw new ImmediateResponseException(
                ->handlePageError($GLOBALS['TYPO3_REQUEST'], 'Some bot attack'));

Kind regards
Rozbeh Chiryai Sharahi


Also available in: Atom PDF