Skip to Content


Many abap developers may not have authorization to use many of the transactions. E.g.



There is a way to use any transaction even though you don’t have access. The Function module C14Z_TRANSACTION_CALL can be used.


1. Go to transaction se37:


2. Give the FM “C14Z_TRANSACTION_CALL” and click ‘Display’


3. Put a debugger at line no 44


4. Execute(F8) and give the Tcode that you want to use.


5. Then Execute. It will open a debugger session. double click on SY-SUBRC and see the value equal to 2.


6. Go to edit mode and make the SYSUBRC value equal to 1.


7. Execute and enjoy


It is not recommended to use the transaction which you are not authorized to view.

You must be Logged on to comment or reply to a post.
  • I think education and openness are good things. Security through obscurity has been disproven to work. If there's a security hole in a system, it is much better to educate everybody on it so that appropriate countermeasures can be taken than to hope that the bad guys won't be among the random sample of people who know about this.

    If you don't educate people, chances are that the bad guys will know far more vulnerabilities than the good guys do. Therefore, I suggest a positive approach and turn this into a competition.

    Looking at the vulnerability described here, how would you fix it?

    Send your entries to howwouldyoufixit at gmx dot de. The deadline is Monday, Nov 25, 12 noon CET (Berlin/Amsterdam/Walldorf).



    • Hi Thorsten,

      I agreed whole-heartedly. For any SAP governance perspective, it helps one to evaluate the SAP environment is secured enough to prevent such activities from happening. It definitely triggers me to think how safe my SAP environment is under this scenario.



    • You're absolutely right, but it isn't a hole in the security but a not professional management of the user authorizations.

      It happens to many customers and you have to mentor them that what they are doing is not properly in the SAP best practice.

    • Although it is also (if you have control over changing variable in code) easy enough to bypass the logging too (or at least delete the log). But no-one would be that malicious would they? 😈

  • Hi Ajit,

    I think it's all very fun to know how to get around the security authorizations which have been put in place, probably for a reason. 

    But if one actually exercises this, particularly in a production environment, they are putting their job, and their customer's data integrity at risk. 

    However, I love Thorsten's idea about turning this around into a competition about how you would fix this vulnerability.

    Since I am not a security guru, I would delimit your userid and have you escorted off the premises.  And then I would ensure that everyone else with access to SE37 (which should also be restricted in production, to say the least) knows why.

    However, you do put the disclaimer at the end, so hopefully that would be enough to stop the bad guys. 


    • If just stopping transactions is the security team's view of how to secure things, it is they that should be fired and sent off the premise. Any user that is allowed to modify sy-subrc in debugger has effectively been given SAP_ALL auths.

      Now there may be very good reasons that some people have those auths - but you should remember what level of access you are giving them.

      • Hi Chris,

        "Any user that is allowed to modify sy-subrc in debugger has effectively been given SAP_ALL auths".

        I'm thinking, if SAP expects ALL SAP Security person to know this then it should be included in their training curriculum ADM940. It should perhaps have a section to tell them how to stop people from doing things through the back door right from day 1 they start the role as a SAP Security person.

        Side track a little. I was at SAUG, thanks for last question that you asked the CIOs, I thought that's a good question.



  • Execute and enjoy

    and then adding your disclaimer at the end

    It is not recommended to use the transaction which you are not authorized to view.

    is a bit of a contradiction for this article.

    What are you actually trying to achieve with this article? You start by saying 'hey you don't have access so this is what you can do' but end with 'oh if you're not authorised you better not'?

    At the end of the day you are telling a developer how to use debug change mode. If they are a developer I would have thought they would know this already. Most of them would just debug the program they are trying to execute and change the RC to 0 there instead of running a function module.

    A Good security administration would ensure S_DEVELOP for Debug is not assigned in Production. When it comes to non-production, trust of developers/functional analyst/etc is established and the debug access is granted so they can do their job. However, misuse of the access would most likely go against any policy you are meant to adhere to. You would be risking your job to do this.

    Again, as mentioned by others - if debug was granted in Production there is a chance that security audit log would be configured to alert to the use.

  • Hi Ajit,

    There are a couple of more transactions CALL_TRANSACTION_FROM_TABLE and ALINK_CALLTRANSACTION which allow you to do the same. So mention these also in your blog stating multiple ways exist.

    For the gurus,

    Can you please ignite us about the differences between all these FM's which bypass SAP Auth Checks?

  • I think this is much ado about nothing...trivial example at best and not nearly "OMG!!!733T hax0rz!". It is a cute trick (and there are loads more), but in a properly locked down production environment, this will not be an issue.

    ...and he didn't even show playing around with the "destination" of the FMs! hahaha 😛

  • Hi ,

    What is this?? such a silly document. The user is having Debugging authorization but not having other trasaction authorization.

    If user is having debugging authorization ... he can simply bypass the error message in the debugging from the same screen. Why to go to some other Function Module.

    Debugging is th first thing a security cosultant will see before assigning any Authorization.

    I don't like it !!!!

  • It is not just production environment that we should be looking at. What if  your Sandbox, QA get system refreshed from Production and your environment don't have a tool to 'massage' your business data? Then your non-Prod system is equivalent to your Prod system.

  • This is another interesting way to circumvent security restriction.

    Judging from the comments in here the audience is a little split in either

    If you have debugging authorization you can pretty much do anything.


    When you do it you get dispelled, fired, arrested or possibly deported.

    From my point of view the questions we should all ask us are:

    - Why do these ways exist?

    - Why do people invest time to find out about them?

    - Why do people use them?

    For the first two the answer is quite simple: By accident or on purpose.

    The last one is what we should investigate. Why do people use these kind of holes? At least in my humble opinion.

    Just for the record: On production systems I never have and probably never will go around restrictions put in place. (Unless the system owner explicitly requests it with good reason.)

    This said my main reason to know and sometimes use these ways is to speed up development. Often it happens that you are not granted access to transactions you seldomly need like SM59. When it is recognized it is, to my experience always, a longer way to get official access or find someone who has and knows how to use it.

    Now being put in front of the decision: Stop working until you get access or just go around the problem?

    To have some more partial disclosure I could introduce some things myself:

    • Use SE93 to display a transaction and then execute the report behind directly
    • If no access to SE93 check the report behind the transaction on another system and start SA38.

    Still no luck?

    • Maybe one of the Basis admins did a bad job in setting up remote users...

    This list is in no way complete! I am quite confident these techniques are widely known by SAP developers. Thus creating no harm to list them up here again.



    • Carsten Kasper wrote:

      Still no luck?

      • Maybe one of the Basis admins did a bad job in setting up remote users...


      I think you meant good job..  🙂

      Anyway, my problem with this type of blog is that it encourages people to work the wrong way, and then they claim that they cannot do their daily jobs without having access to change variables in the debugger. That it is possible to debug is nothing new and was actually not required here either. Very silly IMO.



      • Julius von dem Bussche wrote:


        That it is possible to debug is nothing new and was actually not required here either. Very silly IMO.                   

        Totally agree with you there. The only reason I stumbled into this thread is the rumour it created not only on SCN but as well on Twitter. Just count the comments!

        Still I fear that the topics discussed and the questions raised here so far will not be answered when this thread is long forgotten. I would really love to see some result, being it through Thorsten Franz challenge or just by clarifying the status of such posts on SCN.



  • Interesting blog. Strange how it's evolving, though.

    Let me add some of my (security researcher) perspective to it.

    As far as I see it, Ajit started the blog to point out that there are circumstances that allow unauthorized users to do things they're not supposed to do. In his example the circumstances are caused by a rather "interesting" roles configuration.

    The "Security by Obscurity" discussion went to the right direction. Talking about bugs (in a responsible way) serves the greater good far more than trying to cover them up. Believe me: the bad guys know they are there, anyway.

    The "How to fix" discussion is also good, because talking about bugs alone does not make the world better. We need to understand that there are problems and we need to discuss solutions. Unfortunately the only party that can really fix this problem at its root is SAP. And this is also why part of this discussion went to the wrong direction.

    Well, customers can try to maintain their debug authorizations more strictly. Although (discussed in the thread above) sometimes "extended" authorizations may be required to get things done efficiently. But even if debug authorizations are locked down: there are so many alternatives to start transactions, that it's extremely difficult to block them all.

    There are a number of "transaction starters" in the SAP standard, some can be invoked via reports, some via (remote enabled) function modules. Some have been already discussed in the blog, some I'd like to add from my own research:

    • Advisory VF-BACK-17 (SAP Note 1774903)
    • Advisory VF-BACK-18 (SAP Note 1775422)
    • Advisory VF-MAC-01 (SAP Note 1789823)

    All have been responsibly reported to SAP, none of the programs originally contained an authority check, but all are fixed for some time now.

    So customers also need to apply all patches in a very timely fashion in order to prevent users from starting restricted transactions (via previously unknown bugs).

    But this still doesn't solve the problem. A single piece of custom code can create a new transaction starter. Actually it takes only two lines of (custom) ABAP code in order to start an arbitrary transaction. One could now argue that customers should scan all their custom code for this and fix/remove all transaction starters. But this would still not be the real solution to the problem. Because all of the above "solutions" only address the symptom, not the root cause. The symptom is that someone manages to execute a restricted transaction with a trick. The root cause is that the called transaction itself does not properly check if the user has the necessary authorizations to execute its business logic. If the transaction did, it would not matter, if some unauthorized user could start it: It would not work. Unless of course the user had all the required authorizations. But if a user had these, he/she would by definition be allowed to run the transaction.

    Disclaimer: I am not saying that all SAP standard transactions do not properly enforce authorization checks. But obviously there are some. Otherwise we would not be having this discussion, would we?

    My proposal for a general solution: always make sure your transactions (SAP standard and custom) sufficiently enforce all required authorizations to run them.

    The "Fire (people like) Ajit" discussion is out of place IMHO. Of course, no one wants employees that hack their company. But Ajit was not hacking a company. He was pointing out a specific security loophole that could be misused. And thereby he created awareness. Which is the first step in becoming more secure. And that is good.

    So I say, we need more people like Ajit that have the courage to bring problems to light.

    • Thank you Andreas. That is just my point of view!

      One thing I would like to add: It should be strongly differentiated between developers and general users. On the development environment developers should be able to do their work. Starting on Quality these authorizations need to be narrowed down. On production they should be really limited.

      Of course this means that Basis has to setup multiple Roles... Which leads to additional effort necessary.

      If SAP really can close all holes on a system that is used for development is questionable to me. Either you do the Java setting and take care of everything while limiting the user or you do it like C and allow potential pitfalls.



    • Hi Andreas

      I respect your opinion, however....

      The title of the blog is "Work around" - Not authorised to use a transaction.

      i.e if you haven't been given access to a transaction, this is a short cut to gaining access.

      Not "Security hole that people need to be aware of"

      The issues are completely different and can be raised and pointed out in the correct way.



  • Hmmm... not so much a work around or security hole as "why you don't give out debug authority lightly in production".

    Sometimes these approaches are needed in emergency situations.

    Security and authorizations folks should take note! 

    Frankly if you have an emergency situation its better to have a "fireman access" user id with SAP_ALL authority that has special protections around it - I've seen a number of sites use that approach including requirements to login stating your reasons for using the user id, automatic closing of the password afterwards, and regular review of usage.  A lot more effective than debugging.