#nginx

Microsoft Internet Information Services (IIS) is a web server software package designed for Windows Server. Organizations commonly use Microsoft IIS servers to host websites, files, and other content on the web. Threat actors increasingly target these Internet-facing resources as low-hanging fruit for finding and exploiting vulnerabilities that facilitate access to IT environments.  Recently, a

Parse Server is an open source backend server. In affected versions the Parse Cloud trigger `beforeFind` is not invoked in certain conditions of `Parse.Query`. This can pose a vulnerability for deployments where the `beforeFind` trigger is used as a security layer to modify the incoming query. The vulnerability has been fixed by refactoring the internal query pipeline for a more concise code structure and implementing a patch to ensure the `beforeFind` trigger is invoked. This fix was introduced in commit `be4c7e23c6` and has been included in releases 6.2.2 and 5.5.5. Users are advised to upgrade. Users unable to upgrade should make use of parse server's security layers to manage access levels with Class-Level Permissions and Object-Level Access Control that should be used instead of custom security layers in Cloud Code triggers.

Our previous blog discussed the persistent volume challenges with peer-pods and how to resolve them. It also introduced using the CSI wrapper as a potential solution to the persistent volume usage challenges with peer-pods. This post dives deeper into the various components that make up the persistent volume solution in peer-pods. Interpreting the CSI plugins in peer-pods To use persistent volumes in peer-pods, intercept the CSI Plugins in the control plane (CSI Controller Plugin) and worker node (CSI Node Plugin) through the CSI Wrapper approach. With the CSI Wrapper injected into C

An issue in Pagekit pagekit v.1.0.18 alows a remote attacker to execute arbitrary code via thedownloadAction and updateAction functions in UpdateController.php

Datasette is an open source multi-tool for exploring and publishing data. This bug affects Datasette instances running a Datasette 1.0 alpha - 1.0a0, 1.0a1, 1.0a2 or 1.0a3 - in an online accessible location but with authentication enabled using a plugin such as datasette-auth-passwords. The `/-/api` API explorer endpoint could reveal the names of both databases and tables - but not their contents - to an unauthenticated user. Datasette 1.0a4 has a fix for this issue. This will block access to the API explorer but will still allow access to the Datasette read or write JSON APIs, as those use different URL patterns within the Datasette `/database` hierarchy. This issue is patched in version 1.0a4.

The web server Tengine 2.2.2 developed in the Nginx version from 0.5.6 thru 1.13.2 is vulnerable to an integer overflow vulnerability in the nginx range filter module, resulting in the leakage of potentially sensitive information triggered by specially crafted requests.

### Impact This bug affects Datasette instances running a Datasette 1.0 alpha - 1.0a0, 1.0a1, 1.0a2 or 1.0a3 - in an online accessible location but with authentication enabled using a plugin such as [datasette-auth-passwords](https://datasette.io/plugins/datasette-auth-passwords). The `/-/api` API explorer endpoint could reveal the names of both databases and tables - but not their contents - to an unauthenticated user. ### Patches Datasette 1.0a4 has a fix for this issue. ### Workarounds To work around this issue, block all traffic to the `/-/api` endpoint. This can be done with a proxy such as Apache or NGINX, or by installing the [datasette-block](https://datasette.io/plugins/datasette-block) plugin and adding the following configuration to your `metadata.json` or `metadata.yml` file: ```json { "plugins": { "datasette-block": { "prefixes": ["/-/api"] } } } ``` This will block access to the API explorer but will still allow access to the Dat...

Pikachu v1.0 was discovered to contain a SQL injection vulnerability via the $username parameter at \inc\function.php.

An issue was discovered in Tigergraph Enterprise 3.7.0. The TigerGraph platform installs a full development toolchain within every TigerGraph deployment. An attacker is able to compile new executables on each Tigergraph system and modify system and Tigergraph binaries.

An issue was discovered in Tigergraph Enterprise 3.7.0. The GSQL query language provides users with the ability to write data to files on a remote TigerGraph server. The locations that a query is allowed to write to are configurable via the GSQL.FileOutputPolicy configuration setting. GSQL queries that contain UDFs can bypass this configuration setting and, as a consequence, can write to any file location to which the administrative user has access.