HTTP allows responses to be cached, even if they don't have explicit Expires or Cache-Control headers.
Specifically, they're allowed to calculate their own so-called heuristic freshness for responses with certain HTTP status codes (including
200 OK). Usually, this is based upon the value of the
Last-Modified header; e.g., if LM is 1 day ago when the response is first stored, a cache might figure that it's safe to assume it's fresh for 2 hours.
must-revalidate is an instruction that tells caches that once something becomes stale, it has to be checked on the origin server. If it isn't present, caches can (generally) use stale responses in unusual circumstances (e.g., if they lose contact with the origin server).
So, no, this cache doesn't look like it's misbehaving, although it sounds like it might be a bit aggressive in calculating heuristic freshness. If you don't want the cache to store the response at all, try
Cache-Control: no-store, or (preferably) just set an explicit
max-age to control how long it's considered fresh.
You might be interested in having a look at the IETF HTTPbis Working Group's current document that covers caching:
which hopefully makes this a bit clearer than RFC2616.
Also, http://redbot.org/ will check URLs and explain how caches handle specific response directives.