It happens on BSP draw surfaces that use vertex lighting instead of a lightmap. You can check the lightmap number to see if vertex lighting should be used.
#define LIGHTMAP_2D -4 // shader is for 2D rendering
#define LIGHTMAP_BY_VERTEX -3 // pre-lit triangle models
#define LIGHTMAP_WHITEIMAGE -2
#define LIGHTMAP_NONE -1
For planar, patch, and flare surfaces; LIGHTMAP_BY_VERTEX is used for vertex lit surfaces, otherwise it should have a lightmap number greater or equal to 0 for an actual lightmap. See the next section for triangle surfaces.
LIGHTMAP_2D should not appear in BSP files. It’s used internally by the engine. LIGHTMAP_WHITEIMAGE uses a solid white lightmap; I don’t think it’s used by q3map or q3map2 but I’m not 100% sure.
The original q3map uses LIGHTMAP_NONE for vertex lit misc_model triangle surfaces. Lightmapped misc_models are not supported. Q3 and RTCW engines force all BSP triangle surfaces to use LIGHTMAP_BY_VERTEX regardless of the actual lightmap number. LIGHTMAP_NONE is also used internally by the engine for 3D models and does not render correctly on BSP surfaces.
q3map2 uses LIGHTMAP_BY_VERTEX or a real lightmap (the same as the other surface types) for BSP triangle surfaces. ET engine supports vertex lit and lightmapped BSP triangle surfaces.
So in my Spearmint fork of ioquake3 for instance, I treat LIGHTMAP_NONE on BSP triangle surfaces as LIGHTMAP_BY_VERTEX and support all other lightmap numbers as usual in order to support maps made with q3map and q3map2.