An issue was discovered in OpServices OpMon 9.3.2. Starting from the apache user account, it is possible to perform privilege escalation through the lack of correct configuration in the server's sudoers file, which by default allows the execution of programs (e.g. nmap) without the need for a password with sudo.

An issue was discovered in OpServices OpMon 9.3.2. Without authentication, it is possible to read server files (e.g., /etc/passwd) due to the use of the nmap -iL (aka input file) option.

rendersystemdx9.dll in Valve Dota 2 before 7.23f allows remote attackers to achieve code execution or denial of service by creating a gaming server and inviting a victim to this server, because a crafted map is affected by memory corruption.

meshsystem.dll in Valve Dota 2 before 7.23e allows remote attackers to achieve code execution or denial of service by creating a gaming server and inviting a victim to this server, because a crafted map is affected by memory corruption.

meshsystem.dll in Valve Dota 2 before 7.23f allows remote attackers to achieve code execution or denial of service by creating a gaming server and inviting a victim to this server, because a crafted map is mishandled during a vulnerable function call.

schemasystem.dll in Valve Dota 2 before 7.23f allows remote attackers to achieve code execution or denial of service by creating a gaming server and inviting a victim to this server, because a crafted map is mishandled during a GetValue call.

An issue was discovered in the Login by Auth0 plugin before 4.0.0 for WordPress. A user can perform an insecure direct object reference.

An issue was discovered in the Login by Auth0 plugin before 4.0.0 for WordPress. It has numerous fields that can contain data that is pulled from different sources. One issue with this is that the data isn't sanitized, and no input validation is performed, before the exporting of the user data. This can lead to (at least) CSV injection if a crafted Excel document is uploaded.

puppet: local registry credentials included in CD4PE deployment definition leads to expose credentials to users who should not have access

Local registry credentials were included directly in the CD4PE deployment definition, which could expose these credentials to users who should not have access to them. This is resolved in Continuous Delivery for Puppet Enterprise 4.0.1.

In Continuous Delivery for Puppet Enterprise (CD4PE) before 3.4.0, changes to resources or classes containing Sensitive parameters can result in the Sensitive parameters ending up in the impact analysis report.

puppet: puppet server and puppetDB may leak sensitive information via metrics API

Puppet Server and PuppetDB provide useful performance and debugging information via their metrics API endpoints. For PuppetDB this may contain things like hostnames. Puppet Server reports resource names and titles for defined types (which may contain sensitive information) as well as function names and class names. Previously, these endpoints were open to the local network. PE 2018.1.13 & 2019.5.0, Puppet Server 6.9.2 & 5.3.12, and PuppetDB 6.9.1 & 5.2.13 disable trapperkeeper-metrics /v1 metrics API and only allows /v2 access on localhost by default. This affects software versions: Puppet Enterprise 2018.1.x stream prior to 2018.1.13 Puppet Enterprise prior to 2019.5.0 Puppet Server prior to 6.9.2 Puppet Server prior to 5.3.12 PuppetDB prior to 6.9.1 PuppetDB prior to 5.2.13 Resolved in: Puppet Enterprise 2018.1.13 Puppet Enterprise 2019.5.0 Puppet Server 6.9.2 Puppet Server 5.3.12 PuppetDB 6.9.1 PuppetDB 5.2.13

puppet: Arbitrary catalog retrieval

Previously, Puppet operated on a model that a node with a valid certificate was entitled to all information in the system and that a compromised certificate allowed access to everything in the infrastructure. When a node's catalog falls back to the `default` node, the catalog can be retrieved for a different node by modifying facts for the Puppet run. This issue can be mitigated by setting `strict_hostname_checking = true` in `puppet.conf` on your Puppet master. Puppet 6.13.0 and 5.5.19 changes the default behavior for strict_hostname_checking from false to true. It is recommended that Puppet Open Source and Puppet Enterprise users that are not upgrading still set strict_hostname_checking to true to ensure secure behavior. Affected software versions: Puppet 6.x prior to 6.13.0 Puppet Agent 6.x prior to 6.13.0 Puppet 5.5.x prior to 5.5.19 Puppet Agent 5.5.x prior to 5.5.19 Resolved in: Puppet 6.13.0 Puppet Agent 6.13.0 Puppet 5.5.19 Puppet Agent 5.5.19

plone: privilege escalation for overwriting content without needing write permission

A privilege escalation issue in plone.app.contenttypes in Plone 4.3 through 5.2.1 allows users to PUT (overwrite) some content without needing write permission.

plone: missing password strength checks on some forms

Missing password strength checks on some forms in Plone 4.3 through 5.2.0 allow users to set weak passwords, leading to easier cracking.

plone: SQL injection due to insufficient SQL quoting in DTML or in connection objects

SQL Injection in DTML or in connection objects in Plone 4.0 through 5.2.1 allows users to perform unwanted SQL queries. (This is a problem in Zope.)

plone: privilege escalation in plone.restapi

plone.restapi in Plone 5.2.0 through 5.2.1 allows users with a certain privilege level to escalate their privileges up to the highest level.

plone: XSS in the title field

An XSS issue in the title field in Plone 5.0 through 5.2.1 allows users with a certain privilege level to insert JavaScript that will be executed when other users access the site.

plone: open redirection on the login form and possibly other places

An open redirect on the login form (and possibly other places) in Plone 4.0 through 5.2.1 allows an attacker to craft a link to a Plone Site that, when followed, and possibly after login, will redirect to an attacker's site.

Artica Pandora FMS through 7.42 is vulnerable to remote PHP code execution because of an Unrestricted Upload Of A File With A Dangerous Type issue in the File Manager. An attacker can create a (or use an existing) directory that is externally accessible to store PHP files. The filename and the exact path is known by the attacker, so it is possible to execute PHP code in the context of the application. The vulnerability is exploitable only with Administrator access.

In LifeRay Portal CE 7.1.0 through 7.2.1 GA2, the First Name, Middle Name, and Last Name fields for user accounts in MyAccountPortlet are all vulnerable to a persistent XSS issue. Any user can modify these fields with a particular XSS payload, and it will be stored in the database. The payload will then be rendered when a user utilizes the search feature to search for other users (i.e., if a user with modified fields occurs in the search results). This issue was fixed in Liferay Portal CE version 7.3.0 GA1.