The implementation of the flash scope in Mojarra 2.x is based on a cookie that contains an index into an application scoped map. This index is a simple integer. New values are obtained by the implementation by incrementing an AtomicInteger:
This algorithm makes the index very predictable. Since the map that contains all flash data is application scoped, an attacker only needs to known an index in order to access data from random other users. As mentioned this index is very easy to guess. One scheme would be to observe the index being handed out for a particular request (say 1500), then take a slightly higher number (say 2000) and continuously poll the server using this cookie. Eventually this number will be generated server side and it's possible the attacker's request will reach the server before that of the legitimate user.
This exploit is even more severe since all current Mojarra implementations (2.0.x and 2.1.x) contain other bugs that prevent the flash scope from being immediately expired (see http://java.net/jira/browse/JAVASERVERFACES-1751). The user has to do a couple of post backs before this expiration actually happens. This means in the current situation there's a very wide window where the attacker can access data with a guessed index.
Since the Flash scope can contain any kind of data (like e.g. personal information, credit card details, messages, etc) this seems be a rather severe problem.
One solution would be to use a GUID instead of a sequential number. Another solution could be to (optionally) store flash data in the HTTP session and thus piggyback on the security of the JSESSIONID.