XPRA actions can be a must to to trigger actions after import. The most know is to trigger the RV80HGEN program jointly with update of requirement or formula.
The XPRA can also be misused by hackers to execute actions right after transport import. Since XPRA is done with the DDIC user upon import, it will take the rights from DDIC as well. Very often DDIC has SAP_ALL assigned.
Correct usage of XPRA
To add a XPRA action, go to the transport via SE10 or SE01 and press change. Then use the Insert Row button to manually add the XPRA action:
Add program ID R3TR, object type XPRA and object name the program to be executed. In this case the RV80GHEN program.
Now save the transport.
Upon import the program will be executed at the end of the import. This can be seen in the transport import log details:
Other XPRA programs
Next to RV80GHEN there are more known XPRA programs:
2400599 – List of Programs to regenerate CUSTOM fields after upgrade or patch update lists RGUGBR02, SAPFACCG and RFBIBLG0.
1365712 – Generating FI programs during posting after importing an SP lists program RGZZGLUX to regenerate the finance programs.
1855686 – Dump in XPRA phase because of FAGL_VIEWS_GENERATE_ALL lists program SAPLFAGL_VIEWS_GENERATE (and old program SAPFACCG).
Misuse of XPRA
Off course any developer can add a malicious XPRA statement to execute a program upon import.
What to do about this?
Prevention is not possible. Detection is possible. See the blog on adding a critical object check to the transport check tool. In this case add a check on R3TR XPRA and program *. This will detect any XPRA object.