Mass personal message broadcast in Bitrix24

Security fixes.

IDOR on attachments, high severity (components/masspersonalmessage.sender/class.php, handleSendAction): The MODULE_ID check for the file was common to all module users, so a user with the access_module right could, by iterating sequential IDs (attachments=[N]), attach a file uploaded by another module user to their own broadcast and obtain its content. Now, when a file is uploaded (handleFileUpload), its owner is recorded in the user's session; when sending (handleSendAction), only files uploaded by the current user in the same session are accepted.

Incorrect field in owner verification during access revocation (handleRevokeAccess): Only the original requester (UF_KMPM_USER_ID) could revoke a permission granted on their behalf, not the identity owner (UF_KMPM_REQUESTED_USER_ID) on whose behalf the permission was granted. As a result, the identity owner could not independently revoke a right they had previously granted. Now, revocation is available to both parties.

Insufficiently strict file upload, defense-in-depth (handleFileUpload): The MFI controller was passed the 'any file' mode (allowUpload=A), and the module identifier and forceMd5 were taken from the request. An explicit allowlist of allowed extensions has been set, a fixed moduleId is used, and forceMd5=false.

Security fix.

Authentication bypass, defense-in-depth (components/masspersonalmessage.sender/class.php, executeComponent): AJAX actions and file uploads of the component checked only the CSRF token (check_bitrix_sessid), but not authorization and access rights to the module—the component relied on the including page having performed this check. Since the component is reusable (can be included on any page/template), authorization and access_module checks have been moved inside the component itself—now it is protected regardless of where it is included.

Security fix.

IDOR on attachments (components/masspersonalmessage.sender/class.php, handleSendAction): the server only checked for the existence of a file by ID, not its ownership by the module — a user with access rights could attach any file from the Bitrix storage to the mailing by guessing the ID. Now it additionally checks that the file was uploaded via this module's widget (MODULE_ID = kuratovru.masspersonalmessage).

Security fix.

Stored XSS (components/masspersonalmessage.sender/class.php, handleRequestAccess): the requested user's name (user_name), constructed from the NAME/LAST_NAME/SECOND_NAME profile fields, was returned in the JSON response without escaping and inserted on the client side via innerHTML. The user_name value is now escaped using htmlspecialcharsbx() before being sent in the response.

Security fixes.

Authentication bypass (admin/access_module.php): the AJAX handler (add_user/delete_user) was executed before checking administrator rights—any authorized user could grant or revoke access to the module for themselves. The rights check has been moved to the very beginning of the file and is unconditionally performed for all actions.

IDOR (components/masspersonalmessage.sender/class.php): handlers for approving/rejecting/revoking a request to send on behalf of another did not verify that the current user is a participant in the record. A check comparing the current user with the record fields has been added before performing the action.

XSS (class.php, handleRequestAccess): requested_user_id from the request was inserted into the JSON response without type casting. The value is now cast to (int) immediately after retrieval.

XSS (templates/.default/template.php): user names (USER_NAME), formed from profile fields, were output to the template without escaping. All user output is now escaped via htmlspecialcharsbx().

Information leak (install/public/index.php): the Bitrix debug mode (BX_DEBUG) was enabled on the module's public page, revealing error details and internal paths. Debug mode has been disabled.

Compatibility with PHP 8.2.

The access administration page admin/access_module.php contained the short PHP opening tag short PHP opening tag endif; PHP closing tag instead of the PHP opening tag PHP opening tag endif; PHP closing tag. With the short_open_tag directive disabled, this caused a fatal syntax error, and the page would not open.

The class.php mail component did not explicitly declare the $arResult property, which in PHP 8.2 is marked as deprecated dynamic property creation. The property is now explicitly declared.