Security report: admin confirmation can be bypassed with a user confirmation hash

In femanager's registration confirmation flow, the admin approval action can be triggered with the regular user confirmation hash when the default confirmation settings are used. The admin email template generates a separate adminHash, but the default state-changing path for status=adminConfirmation does not require that adminHash.
In addition, even on a confirmByAdmin-only site, an attacker can obtain the regular user confirmation hash for their own pending account through the public resend confirmation action. resendConfirmationMailAction() sends the user confirmation email for the submitted email address without checking whether settings.new.confirmByUser is enabled.
Affected version checked:

• Package: in2code/femanager
• Latest tag checked: 13.3.3
• Latest tag commit checked: 03eeca1992bd9d1a556eef2645427855db16c4f2
• TYPO3 core requirement: ^13.4.0
• Local older version also checked: 13.3.1

The reproduction checks the plugin exposure, resend source, token generation, pending disabled-user lookup, admin confirmation dispatch, missing adminHash requirement, and final account enable sink.
I also reproduced the issue in a TYPO3 13.4.27 HTTP runtime lab. A browser-submitted forged POST changed the pending user from disable=1, tx_femanager_confirmedbyadmin=0 to disable=0, tx_femanager_confirmedbyadmin=1. The cHash-related behavior used by the lab matches femanager's own default TypoScript, which sets plugin.tx_femanager.features.requireCHashArgumentForActionArguments = 0.
Short exploit scenario:

1. A site uses femanager registration with admin approval enabled (confirmByAdmin).
2. An attacker registers a new account with their own email address.
3. The account is stored as disabled and waits for admin approval.
4. The attacker submits their email address to the public resend confirmation action.
5. resendConfirmationMailAction() sends a normal user confirmation email, even when the site is only using admin confirmation.
6. The attacker extracts the regular hash and user arguments from that user confirmation link.
7. The attacker submits a POST request to the confirmation action with status=adminConfirmation, the same user, the same regular hash, and no adminHash.
8. The forged request is not blocked by cHash, because femanager's own TypoScript explicitly sets plugin.tx_femanager.features.requireCHashArgumentForActionArguments = 0 (Configuration/TypoScript/Main/setup.typoscript:21,1789,1814). The POST submission used in my PoC also avoids any GET-cHash check on the action arguments.
9. With the default confirmAdminConfirmation = 0, the optional adminHash guard is skipped.
10. statusAdminConfirmation() validates only the regular hash and then sets the user to tx_femanager_confirmedbyadmin=true and disable=false.

Note: The "Resend Confirmation Mail" plugin in general creates an email with a valid confirmation link for the user, which allows to bypass possible admin confirmation.

Ticket: https://projekte.in2code.de/issues/81406