Una vulnerabilidad crítica sin parchear en LMCache permite a atacantes no autenticados ejecutar código de forma remota

Exis­te una vul­ne­ra­bi­li­dad crí­ti­ca en LM­Ca­che, un pro­gra­ma de có­di­go abier­to que ace­le­ra ser­vi­do­res de mo­de­los gran­des de len­gua­je, la cual per­mi­te a usua­rios no au­ten­ti­ca­dos eje­cu­tar có­di­go de ma­ne­ra re­mo­ta en el ser­vi­dor de caché. Este fallo se en­cuen­tra en el modo mul­ti­pro­ce­so de la he­rra­mien­ta, donde el caché fun­cio­na como un ser­vi­dor in­de­pen­dien­te al que los tra­ba­ja­do­res se co­nec­tan me­dian­te la bi­blio­te­ca de men­sa­je­ría Ze­roMQ. El pro­ble­ma surge por­que el soc­ket ca­re­ce de au­ten­ti­ca­ción y uti­li­za un for­ma­to de Python vul­ne­ra­ble para pro­ce­sar men­sa­jes antes de ve­ri­fi­car su tipo, per­mi­tien­do que un men­sa­je ma­ni­pu­la­do eje­cu­te ins­truc­cio­nes con los pri­vi­le­gios del pro­ce­so.

La ex­po­si­ción del ser­vi­dor de­pen­de de la con­fi­gu­ra­ción de red ele­gi­da por el ope­ra­dor. Por de­fec­to, el sis­te­ma es­cu­cha úni­ca­men­te en la má­qui­na local, pero se vuel­ve ac­ce­si­ble desde otros equi­pos si se con­fi­gu­ra con una di­rec­ción en­ru­ta­ble, tal como ocu­rre en al­gu­nos des­plie­gues en Ku­ber­ne­tes o en im­ple­men­ta­cio­nes donde múl­ti­ples nodos com­par­ten el caché. Cuan­do esto su­ce­de y el ser­vi­dor se eje­cu­ta en una ima­gen ofi­cial de con­te­ne­do­res, el có­di­go ma­li­cio­so puede lle­gar a eje­cu­tar­se con per­mi­sos de root.

Hasta el mo­men­to no se ha lan­za­do una ver­sión co­rre­gi­da de LM­Ca­che ni se ha pu­bli­ca­do un aviso de se­gu­ri­dad por parte de sus crea­do­res. Como me­di­da pro­vi­sio­nal, se re­co­mien­da evi­tar el uso de di­rec­cio­nes en­ru­ta­bles para el ser­vi­dor mul­ti­pro­ce­so, man­te­nién­do­lo en la red local o en un clús­ter de con­fian­za, y li­mi­tan­do el ac­ce­so me­dian­te cor­ta­fue­gos, aun­que esto úl­ti­mo no eli­mi­na por com­ple­to el pe­li­gro. Adi­cio­nal­men­te, se han re­por­ta­do otros fa­llos po­ten­cia­les re­la­cio­na­dos con el ac­ce­so no au­ten­ti­ca­do a datos y ser­vi­cios, mien­tras que un pro­ble­ma si­mi­lar que cau­sa­ba de­ne­ga­ción de ser­vi­cio en vLLM ya cuen­ta con una so­lu­ción pre­via.