In agreement with @thedaian, I think you'll find these companies who work in social (and) web games tend to have various different "templates" (engines, if you will, although that term to my mind implies a lot more) that they can re-engineer to various purposes. For example, a multi-directional top-down action engine, a platformer engine, an RTS-type engine... and so on. These templates are usually games they've either bought the code rights to, or more often have developed earlier on in their own existence.
Obviously this works well both internally, and if you are being contracted by clients to produce games, advergaming being the perfect example.
The thing is, since each game is so small and relatively easy to refactor into something else, there's often not a drive to actually properly factor out the engine aspects as an engine. That's more the domain of middleware sold by dedicated middleware vendors, where you want to provide a perfect, clean slate for customers to work with. In the continuum of games/front-end/interactive I've worked in, I've seen pretty consistent code reuse this way. Obviously, though, these companies are also building other, completely new codebases, even as they are reusing the old to increase revenues.
More generally, there is little reason for them not to use mature external frameworks/engines like Flixel or Impact.js to implement new games. Decisions to use middleware can be fraught with risk, however, and so this is not always the chosen route.
In a sense, I guess the engine-vs.-template matter is just me arguing semantics with myself but again, the general answer would be, "Yes, they do".