#auth

### Summary GeoNode is vulnerable to an XML External Entity (XXE) injection in the style upload functionality of GeoServer leading to Arbitrary File Read. ### Details GeoNode's GeoServer has the ability to upload new styles for datasets through the [`dataset_style_upload` view](https://github.com/GeoNode/geonode/blob/99b0557da5c7db23c72ad39e466b88fe43edf82d/geonode/geoserver/urls.py#L70-L72). ```py # https://github.dev/GeoNode/geonode/blob/99b0557da5c7db23c72ad39e466b88fe43edf82d/geonode/geoserver/views.py#L158-L159 @login_required def dataset_style_upload(request, layername): def respond(*args, **kw): kw['content_type'] = 'text/html' return json_response(*args, **kw) ... sld = request.FILES['sld'].read() # 1 sld_name = None try: # Check SLD is valid ... sld_name = extract_name_from_sld(gs_catalog, sld, sld_file=request.FILES['sld']) # 2 except Exception as e: respond(errors=f"The uploaded SLD file is not valid X...

### Problem TL;DR: Any LTI tool that is integrated with on the Open edX platform can post a grade back for any LTI XBlock so long as it knows or can guess the block location for that XBlock. In LTI 1.3, LTI tools can "pass back" scores that learners earn while using LTI tools to the edX platform. The edX platform then stores those LTI scores in a separate table. If the right conditions are met, these scores are then persisted to the LMS grades tables. LTI tools can create what are called "line items" on the edX platform. A line item can be thought of as a column in a grade book; it stores results for a specific activity (i.e. XBlock) for a specific set of users (i.e. users in the course using the XBlock). A line item has an optional resource_link_id field, which is basically the XBlock location. An LTI tool can supply any value for this field. An LTI tool submits scores to the edX platform for line items. The code that uploads that score to the LMS grade tables determines which XBlo...

# Name Updating a DID with a nym transaction will be written to the ledger if neither ROLE or VERKEY are being changed, regardless of sender. # Description A malicious DID with no particular role can ask an update for another DID (but cannot modify its verkey or role). This is bad because: 1. Any DID can write a nym transaction to the ledger (i.e., any DID can spam the ledger with nym transactions). 1. Any DID can change any other DID's alias. 1. The update transaction modifies the ledger metadata associated with a DID. # Expected vs Observed We expect that if a DID (with no role) wants to update another DID (not its own or one it is the endorser), then the nodes should refuse the request. We can see that requirements in the [Indy default auth_rules](https://github.com/hyperledger/indy-node/blob/master/docs/source/auth_rules.md) in Section "Who is the owner" in the last point of "Endorser using". We observe that with a normal DID, we can update the field `from` for a random DID, ...

GNUnet is a peer-to-peer framework with focus on providing security. All peer-to-peer messages in the network are confidential and authenticated. The framework provides a transport abstraction layer and can currently encapsulate the network traffic in UDP (IPv4 and IPv6), TCP (IPv4 and IPv6), HTTP, or SMTP messages. GNUnet supports accounting to provide contributing nodes with better service. The primary service build on top of the framework is anonymous file sharing.

Water Billing Management System version 1.0 suffers from a cross site request forgery that enables an arbitrary file upload.

Webpay E-Commerce version 1.0 suffers from a directory traversal vulnerability.

SPIP version 4.2.6 suffers from a code execution vulnerability.

WordPress GetYourGuide Ticketing plugin version 1.0.6 suffers from a cross site scripting vulnerability.

WordPress SeatReg plugin version 1.54.0 suffers from an open redirection vulnerability.

WordPress WP Event Manager plugin version 3.1.44 suffers from a cross site scripting vulnerability.