If the UploadWithEmbargoStep is activated users can set embargos on a bitstream level. If such an embargo passes its embargo date it becomes publicly readable if you know the right URL (g.e. dspace.example.org/retrieve/<bitstreamid>).
A untrustworthy submitter can use this to submit a bad bitstream (virus, malware, what ever) with an embargo date of tomorrow. After the embargo end date is reached the file is accessible publicly while the institution that runs DSpace thinks that all submissions have to be reviewed by a DSpace administrator (if the workflows are configured that way).
This situation can be exploited by sending a link that uses a URL which is obviously under the control of the institution that runs DSpace, serving bad content.
I have tested this in JSPUI on DSpace 5.2. I haven't tested this on XMLUI yet, but I would expect this issue to affect XMLUI as well.
I found this problem while investigating
DS-2358. The UploadWithEmbargoStep adds resource policies to unarchived bitstreams. The retrieve servlet is necessary so that epersons which are part of the workflow can check the bitstreams of submissions. It would be good to seperate resource policies for workspace items, workflow items and archived items.