A very good guess, “Mom.”   The handling of the $SESSION variable does look potentially-weak in connection to a persistent environment, but what really freaks me about this code is the specific content of the session-cookie variable.   Although I see the presence of a “secure session-store,” I do not see it being used in the manner that I would expect.   Instead, I see a cookie-value that is provided by the client-side being used, as-is on the server side.

Yet, your post does bring up a very valid thought-point, which should now be considered carefully by the OP.   This code as-written might “work” if ... but, maybe only if ... it is “properly” used.   But, especially given the specfic way that the session-variable is used internally (“cache session here instead of flushing/reading from cookie all the time ...”), what if the OP’s code, by some circuitous obscure path, isn’t using it “quite properly?”

This object as-designed would be particularly vulnerable to “impropriety,” and most-especially in any sort of persistent environment.   Indeed, it would be entirely sufficient to explain the Bug, if two successive requests were dispatched to the same persistent (mod_perl or FastCGI) worker-bee in succession ... yes, there could well be a hole precisely-there . . .