iRODS before 4.3.2 provides an msiSendMail function with a problematic dependency on the mail binary, such as in the mailMS.cpp#L94-L106 reference.
The msiSendMail function implemented in the mailMS.cpp file calls an external mail program without proper verification of its path or identity. According to CWE-426, an attacker can substitute a malicious binary under the name mail by manipulating the PATH environment variable or by providing an appropriate file in a searched location. Since the attack is possible remotely without authentication (AV:N, PR:N, UI:N), it can be exploited for privilege escalation or arbitrary code execution in the context of the iRODS process.
An attacker can gain full control over the iRODS server, which includes confidentiality, integrity, and availability of the system — all three aspects rated as HIGH in the CVSS vector.
iRODS should be updated to version 4.3.2 or later, in which the issue was resolved according to the release information published by the vendor (https://irods.org/2024/05/irods-4-3-2-is-released/).
iRODS (Integrated Rule-Oriented Data System) versions before 4.3.2
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:HIrods
APPIrods< 4.3.2
Related vulnerabilities
Untrusted input execution via igetwild in all iRODS versions before 4.1.11 and 4.2.1 allows other iRODS users ...
irodsServerMonPerf in iRODS before 4.3.2 attempts to proceed with use of a path even if it is not a directory.
Multiple unspecified vulnerabilities in iRODS before 3.1 have unknown impact and attack vectors.