Web Ofisi Emlak V2 Injeção SQL (SQL Injection) via emlak-ara.html

Esta vulnerabilidade de injeção de SQL permite que atacantes não autenticados injetem código SQL malicioso através de parâmetros GET como emlakdurumu, emlaktipi, il, ilce, kelime e semt. Com sucesso, um atacante pode extrair dados sensíveis do banco de dados, como informações de usuários, dados de propriedades e outras informações confidenciais. Além disso, a injeção de SQL pode ser utilizada para realizar ataques de tempo-baseados (time-based blind SQL injection), permitindo que o atacante obtenha informações mesmo sem acesso direto aos resultados das consultas. A exploração bem-sucedida pode levar à exfiltração completa do banco de dados e comprometimento do sistema.

Organizations utilizing Web Ofisi Emlak V2 (2.0.0–V2) for real estate management are at significant risk. This includes small to medium-sized businesses relying on the system for property listings, client management, and financial tracking. Shared hosting environments where multiple users share the same server instance are particularly vulnerable, as a compromise of one user's instance could potentially lead to lateral movement and compromise other users’ data.

• php: Examine web server access logs for requests containing suspicious SQL syntax in GET parameters (e.g., emlak_durumu=1' OR '1'='1). • php: Review the source code of Web Ofisi Emlak, specifically the endpoint handling GET parameters, for unescaped user input used in SQL queries. • generic web: Use curl to test the vulnerable endpoints with various SQL injection payloads:

curl 'http://your-web-ofisi-instance/index.php?emlak_durumu=1' OR '1'='1'

• generic web: Monitor error logs for database-related errors that might indicate a SQL injection attempt.

1. 2026-02-22Disclosure

   disclosure

1. Reservado2026-02-22
2. Publicada2026-02-22
3. Modificada2026-04-07
4. EPSS atualizado2026-03-23

A mitigação primária para CVE-2019-25459 é a atualização para a versão 2.5.4 do Web Ofisi Emlak. Se a atualização imediata não for possível, considere implementar medidas de proteção adicionais. Implemente regras de firewall ou proxy para bloquear solicitações HTTP com parâmetros suspeitos nos endpoints vulneráveis. Valide e sanitize rigorosamente todos os dados de entrada do usuário para evitar a injeção de código SQL. Monitore os logs do servidor em busca de padrões de ataque de injeção de SQL, como consultas SQL incomuns ou erros relacionados ao banco de dados.